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test sequence, test plan, test condition, 
test pattern, and timing information in 
general -purpose object-oriented constructs, 
e.g., C++ objects and classes. In particular, 
the modularity of program development 
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DESCRIPTION 

METHOD AND STRUCTURE TO DEVELOP A TEST PROGRAM FOR 

SEMICONDUCTOR INTEGRATED CIRCUITS 

5 CROSS-REFERENCE TO RELATED APPLICATIONS 

This application claims the benefit of application no. 60/447,839, "Method and 
Structure to Develop a Test Program for Semiconductor Integrated Circuits," filed February 14, 
2003; application no. 60/449,622, "Method and Apparatus for Testing Integrated Circuits," filed 
February 24, 2003; U.S. application no. 10/404,002, 'Test emulator, test module emulator, and 

10 record medium storing programs therein," filed March 31, 2003; and U.S. application no. 
10/403,817, 'Test Apparatus and Test Method," filed March 31, 2003, all of which are 
incorporated herein in their entirety by reference. This application also incorporates by 

reference in its entirety U.S. application no. 'Method and Apparatus for 

Testing Integrated Circuits," filed concurrently herewith, which claims the benefit of application 

15 no. 60/449,622, "Method and Apparatus for Testing Integrated Circuits," filed February 24, 
2003. 

BACKGROUND OF THE INVENTION 

Field of Invention 



20 The present invention relates to the testing of integrated circuits (ICs), and more 

particularly to developing a test program for automated semiconductor test equipment (ATE). 

Description of Related Art 

Today tester manufacturers use their own proprietary languages to develop test 
programs for semiconductor test systems (testers). For example, machines produced by 

25 Advantest Corporation utilize the Test Description Language (TDL), and Credence Systems 
offers its own Waveform Generation Language (WGL). To overcome this degree of 
specialization, IC and tester manufacturers tried to find a common ground by developing IEEE 
standard 1450, the Standard Test Interface Language (STDL). STIL, however, is a highly 
specialized language for defining pins, test commands, timing, etc. Moreover, a test engineer 

30 running STDL nevertheless still needs to translate STDL into the proprietary manufacturer- 
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specific language required by the tester. Thus STIL merely serves as an intermediate language 
that is nonetheless highly specialized and not generally known to programmers. 

Hence, it is desirable to develop a method through which test program can be 
written in a general purpose language. Moreover, this method should allow for easy 
5 development of test programs for an open architecture test system. 

SUMMARY OF THE INVENTION 

This application describes test program development using object-oriented 
constructs, e.g., C++ objects and classes. In particular, this method is suitable for developing 
test programs for an open architecture tester, such as that described in U.S. application serial 
10 nos. 60/449,622, 10/404,002 and 10/403,817, assigned to the assignee of the present invention. 

An embodiment of the present invention provides a method for developing a test 
program by describing test system resources, test system configuration, module configuration, 
test sequence, test plan, test condition, test pattern and timing information in general-purpose 
object-oriented, e.g., C/C++, constructs to test a device under test, e.g., an IC, on a 
1 5 semiconductor test system, such as automated test equipment (ATE). The files containing these 
descriptions are stored in memory, i.e., a computer-readable medium, accessible to the test 
system or related equipment that uses the files. 

Describing test system resources may comprise specifying a resource type, where 
the resource type is associated with at least one test module for applying a test to the IC, 
20 specifying a parameter type associated with the resource type, and specifying a parameter of the 
parameter type. 

Describing test system configuration may comprise specifying a site controller 
for controlling at least one test module, where each test module applies a test to the IC, and 
specifying an input port of a module connection enabler. The test system couples the site 
25 controller to the module connection enabler at the specified input port, and the module 

connection enabler couples the site controller to a test module. The module connection enabler 
may be implemented as a switch matrix. 

Describing module configuration may comprise specifying a module identifier 
for specifying a module type, specifying executable code for controlling a test module of the 
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module type specified by the module identifier, and specifying a resource type associated with 
the test module. The executable code may take the form of a dynamic link library. 

Describing module configuration may further involve the user specifying a slot 
identifier for specifying an output port of the module connection enabler, where the test system 
5 couples the test module to the module connection enabler at the output port, and the module 
connection enabler couples the test module to a corresponding site controller. The user may 
also specify a vendor identifier for identifying the provider of the test module, and an identifier 
of the maximum number of resource units available in connection with the resource type. The 
resource type may be, for example, digital tester pins and the resource units tester channels. 
10 Alternatively, the tester channel resource units may also correspond to resource types such as, 
for example, analog tester pins, RF tester pins, power supply pins, digitizer pins, and arbitrary 
waveform generation pins. An indicator relating to which resource units are disabled may also 
be provided. The resource units indicated as disabled may represent defective resource units of 
the test module. 

1 5 Describing test conditions may comprise specifying at least one test condition 

> group, specifying a specification set including at least one variable; and specifying a selector for 
selecting an expression to be bound to a variable. Association of the test condition group with a 
selector for the specification set defines a test condition. 

Describing a test sequence may comprise specifying the order (or flow) in which 
20 various tests can be applied. 

Describing test patterns may comprise specifying the test patterns, associated 
voltage and current levels, transitions in signal values, corresponding rise and fall times and 
associated timing. 

An embodiment of the present invention also includes the use of preheader files. 

25 A preheader file is compiled to create a header file for a class associated with a test entity. The 
preheader includes a parameter block for specifying parameters for setting at least one attribute 
of the test entity, and a template block for specifying source code that is inserted by a compiler 
into the header file for the test entity class. The header file may be a C++ header file. The test 
entity may be a test and the test entity class may be a test class, for example. The parameters 

30 may relate to pattern lists and test conditions, for example. 
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A pattern compiler of an embodiment of the invention includes at least one 
module-specific pattern compiler, and an object file manager for directing each module-specific 
compiler to compile both a corresponding module-specific section of a pattern source file and a 
common section of the pattern source file. The common section includes information accessible 
to all of the module-specific compilers. An output of the compiler includes at least one module- 
specific pattern data section. Module-specific pattern loaders load into corresponding test 
modules module-specific pattern data from corresponding module-specific pattern data sections 
for execution. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 illustrates a conventional tester architecture. 

> 

Figure 2 illustrates a tester architecture according to an embodiment of the 
present invention. 

Figure 3 illustrates a tester software architecture according to an embodiment of 
the present invention. 

Figure 4 illustrates a test program compiler according to an embodiment of the 
present invention. 

Figure 5 illustrates how different test instances may be derived from a single test 
class according to an embodiment of the present invention. 

Figure 6 illustrates a pattern compiler according to an embodiment of the present 

invention. 

Figure 7 illustrates a ordered pattern tree example according to an embodiment of 
the present invention. 

Figure 8 illustrates another ordered pattern tree example according to an 
embodiment of the present invention. 

Figure 9 illustrates the relationships among files that are required by a test 
program according to an embodiment of the present invention. 

Figure 10 illustrates waveform generation according to an embodiment of the 
present invention. 
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Figure 1 1 illustrates a mapping used for timing according to an embodiment of 
the present invention. 

Figure 12 illustrates another mapping used for timing according to an 
embodiment of the present invention, 

5 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The present invention is generally described in terms of the Open architecture 
test system as disclosed in U.S. application serial nos. 60/449,622, 10/404,002 and 10/403,817 
by the same assignee. Those skilled in the art will recognize, however, that embodiments of the 
1 0 test program development system and method of the present invention are applicable not only to 
an open tester architecture, but also to fixed tester architectures, as well. 

A description of the open architecture test system may be found in U.S. 

application no. , "Method and Apparatus for Testing Integrated Circuits," filed 

concurrently herewith, which claims the benefit of U.S. application no. 60/449,622 by the same 
1 5 assignee. 

Figure 1 illustrates a generalized architecture of a conventional tester showing 
how a signal is generated and applied to a device-under-test (DUT). Each DUT input pin is 
connected to a driver 2 that applies test data, while each DUT output pin is connected to a . 
comparator 4. In most cases, tri-state driver-comparators are used so that each tester pin 
20 (channel) can act either as an input pin or as an output pin. The tester pins dedicated to a single 
DUT collectively form a test site that works with an associated timing generator 6, waveform 
generator 8, pattern memory 10, timing data memory 12, waveform memory data 14, and block 
16 that define the data rate. 

Figure 2 illustrates a system architecture 100 according to an embodiment of the 
25 present invention. A system controller (SysC) 102 is coupled to multiple site controllers 

(SiteCs) 104. The system controller may also be coupled to a network to access files. Through 
a module connection enabler 106, each site controller is coupled to control one or more test 
modules 108 located at a test site 1 10. The module connection enabler 106 allows 
reconfiguration of connected hardware modules 108 and also serves as a bus for data transfer 
30 (for loading pattern data, gathering response data, providing control, etc.). Possible hardware 
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implementations include dedicated connections, switch connections, bus connections, ring 
connections, and star connections. The module connection enabler 106 may be implemented by 
a switch matrix, for example. Each test site 1 10 is associated with a DUT 1 12, which is 
connected to the modules of the corresponding site through a loadboard 1 14. In one 

* 

embodiment, a single site controller may be connected to multiple DUT sites. 

The system controller 102 serves as the overall system manager. It coordinates 
the site controller activities, manages system-level parallel test strategies, and additionally 
provides for handler/probe controls as well as system-level data-logging and error handling 
support. Depending on the operational setting, the system controller 102 can be deployed on a 
CPU that is separate from the operation of site controllers 104. Alternatively a common CPU 
may be shared by the system controller 102 and the site controllers 104. Similarly, each site 
controller 104 can be deployed on its own dedicated CPU (central processing unit), or as a 
separate process or thread within the same CPU. 

The system architecture can be conceptually envisioned as the distributed system 
shown in Figure 2 with the understanding that the individual system components could also be 
regarded as logical components of an integrated, monolithic system, and not necessarily as 
physical components of a distributed system. 

Figure 3 illustrates a software architecture 200 according to an embodiment of 
the present invention. The software architecture 200 represents a distributed operating system, 
having elements for the system controller 220, at least one site controller 240, and at least one 
module 260 in correspondence to related hardware system elements 102, 104, 108. In addition 
to the module 260, the architecture 200 includes a corresponding element for module emulation 
280 in software. 

As an exemplary choice, the development environment for this platform can be 
based on Microsoft Windows. The use of this architecture has side benefits in program and 
support portability (e.g., a field service engineer could connect a laptop which runs the tester 
operating system to perform advanced diagnostics). However, for large compute-intensive 
operations (such as test pattern compiles), the relevant software can be made as an independent 
entity capable of running independently to allow job scheduling across distributed platforms. 
Related software tools for batch jobs are thus capable of running on multiple platform types. 
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As an exemplary choice, ANSI/ISO standard C++ can be taken as the native 
language for the software.Of course, there are a multitude of options available (to provide a 
layer over the nominal C++ interfaces) that allows a third party to integrate into the system with 
an alternative language of its own choice. 

5 Figure 3 illustrates a shading of elements according to their organization by 

nominal source (or collective development as a sub-system) including the tester operating 
system , user components 292 (e.g., supplied by a user for test purposes), system components 
294 (e.g., supplied as software infrastructure for basic connectivity and communication), 
module development components 296 (e.g., supplied by a module developer), and external 
10 components 298 (e.g., supplied by external sources other than module developers). 

From the perspective of source-based organization, the tester operating system 

* 

(TOS) interface 290 include: System Controller to Site Controller interfaces 222, framework 
classes 224, Site Controller to Module interfaces 245, framework classes 246, predetermined 
module-level interfaces, baclq>lane communications library 249, chassis slot IF (Interface) 262, 
15 loadboard hardware IF 264, backplane simulation IF 283, loadboard simulation IF 285, DUT 
simulation IF 287, Verilog PLI (programming language interface) 288 for DUT's Verilog model 
and C/C++ language support 289 for DUT's C/C++ model. 

User components 292 include: a user test plan 242, user test classes 243, 
hardware loadboard 265, and DUT 266, a DUT Verilog model 293 and a DUT C/C++ model 
20 291. 

System components 294 include: system tools 226, communications library 230, 
test classes 244, a backplane driver 250, HW backplane 261, simulation framework 281, 
backplane emulation 282, and loadboard simulation 286. 

* 

Module-development components 296 include: module commands 
25 implementation 248, module hardware 263, and module emulation 284. 

External components 298 include external tools 225. 

The system controller 220 includes interfaces 222 to site controller, framework 
classes 224, system tools 226, external tools 225, and a communications library 230. The 
System Controller software is the primary point of interaction for the user. It provides the 
30 gateway to the Site Controllers of the invention, and synchronization of the Site Controllers in a 
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multi-site/DUT environment as described in U.S. application no. 60/449,622 by the same 
assignee. User applications and tools, graphical user interface (GUT)-based or otherwise, run on 
the System Controller. The System Controller also may act as the repository for all Test Plan 
related information, including Test Plans, test patterns and test parameter files. The memory 
5 storing these files may be local to the system controller or offline, e.g., connected to the system 
controller through a network. A test parameter file contains parameterization data for a Test 
class in the object oriented environment of an embodiment of the invention. 

Third party developers can provide tools in addition to (or as replacements for) 
the standard system tools 226. The standard interfaces 222 on the System Controller 220 
1 0 include interfaces that the tools use to access the tester and test objects. The Tools 

(applications) 225, 226 allow interactive and batch control of the test and tester objects. The 
tools include applications for providing automation capabilities (through, for example, the use 
ofSECS/TSEM,etc.) 

The Communications library 230 residing on the system controller 220 provides 
15 the mechanism to communicate with the Site Controllers 240 in a manner that is transparent to 
user applications and test programs. 

The Interfaces 222 resident in memory associated with the System Controller 
220 provide open interfaces to the framework objects that execute on the System Controller. 
Included are interfaces allowing the Site Controller-based module software to access and 
20 retrieve pattern data. Also included are interfaces that applications and tools use to access the 
tester and test objects, as well as scripting interfaces, which provide the ability to access and 
manipulate the tester and test components through a scripting engine. This allows a common 
mechanism for interactive,, batch and remote applications to perform their functions. 

The Framework Classes 224 associated with the System Controller 220 provide a 
25 mechanism to interact with these above-mentioned objects, providing a reference 

implementation of a standard interface. For example, the site controller 240 of the invention 
provides a functional test object. The system controller framework classes may provide a 
corresponding functional test proxy as a remote system controller-based surrogate of the 
functional test object. The standard functional test interface is thus made available to the tools 
30 on the system controller 220. The framework classes effectively provide an operating system 
associated with the host system controller. They also constitute the software elements that 
provide the gateway to the Site Controllers, and provide synchronization of the Site Controllers 
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in a multi-site/DUT environment This layer thus provides an object model in an embodiment 
of the invention that is suitable for manipulating and accessing Site Controllers without needing 
to deal directly with the Communications layer. 

The site controller 240 hosts a user test plan 242, user test classes 243, standard 
test classes 244, standard interfaces 245, site controller framework classes 246, module high 
level command interfaces (i.e., predetermined module-level interfaces 247, module commands 
implementation 248, backplane communications library 249, and a backplane driver 250. 
Preferably most of the testing functionality is handled by the site controllers 104/240, thus 
allowing independent operation of the test sites 110. 

A Test Plan 242 is written by the user. The plan may be written directly in a 
standard computer language employing object-oriented constructs, such as C++, or described in 
a higher level test programming language to produce C++ code, which can then be compiled 
into the executable test program. For test program development, one embodiment of the 
invention employs assignee's inventive Test Program Language (TPL) compiler. Referring to 
Figure 4, the test program compiler 400 acts in part as a code generator including a translator 
section 402 to translate a test program developer's source files 404 describing tests and 
associated parameters into objectroriented constructs, such as C++ code. A compiler section 
406, in turn, compiles and links the code into executables, e.g., DLLs, to create the test program 
that may be executed by the tester system. Although the application of the TPL code 
generator/translator to test systems is novel, please note that code generators are known in the 
art. Also, the compiler section may be a standard C++ compiler known in the art. 

The test plan creates test objects by using the Framework Classes 246 and/or 
standard or user supplied Test Classes 244 associated with the site controllers, configures the 
hardware using the Standard Interfaces 245, and defines the test plan flow. It also provides any 
additional logic required during execution of the test plan. The test plan supports some basic 
services and provides an interface to the services of underlying objects, such as debug services 
(e.g., break-pointing), and access to underlying framework and standard classes. 

The source code input to the test program compiler 400 includes a Test Plan 
description file that specifies the objects used in a test plan and their relationships to one another. 
This file is translated to C++ code that is executed on the Site Controller in the form of an 
implementation of a standard interface, which may be denoted ITestPlan. This code is 
packaged into a Windows dynamic link library (DLL), which may be loaded onto the Site 
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Controller. The Test Program DLL is generated to have standard known entry points that the 
Site Controller software can use to generate and return the TestPlan object it contains. The 
Site Controller software loads the Test Program DLL into its process space and uses one of the 
entry points to create an instance of the Test Plan object. Once the Test Plan object has been 
5 created, the Site Controller software can then execute the test plan. 

The Framework classes 246 associated with the site controllers are a set of 
classes and methods that implement common test-related operations. The site controller-level 
ftamework includes, for example, classes for power supply and pin electronics sequencing, 
setting level and timing conditions, obtaining measurements, and controlling test flow. The 
10 framework also provides methods for runtime services and debugging. The framework objects 
may work through implementing the standard interfaces. For example, the implementation of 
the TesterPin framework class is standardized to implement a general tester pin interface that 
test classes may use to interact with hardware module pins. 

Certain framework objects may be implemented to work with the help of the 
1 5 module-level interfaces 247 to communicate with the modules. The site controller framework 
classes effectively act as a local operating system supporting each site controller. 

In general more than ninety percent of the program code is data for the device 
test, and the remaining ten percent of the code realizes the test methodology. The device test 
data is DUT-dependent (e.g., power supply conditions, signal voltage conditions, timing 
20 conditions, etc.). The test code consists of methods to load the specified device conditions on to 
ATE hardware, and also those needed to realize user-specified objectives (such as datalogging). 
The framework of an embodiment of the invention provide a hardware-independent test and 
tester object model that allows the user to perform the task of DUT test programming. 

To increase the reusability of test code, such code may be made independent of 
25 any device-specific data (e.g., pin name, stimulus data, etc.), or device-test-specific data (e.g., 
conditions for DC units, measurement pins, number of target pins, name of pattern file, 
addresses of pattern programs). If code for a test is compiled with data of these types, the 
reusability of the test code would decrease. Therefore, according to an embodiment of the 
invention, any device-specific data or device-test-specific data may be made available to the test 
30 code externally, as inputs during code execution time. 
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hi an embodiment of the invention, a Test Class, which is an implementation of a 
standard test interface, denoted here as I Test, realizes the separation of test data and code (and 
hence, the reusability of code) for a particular type of test Such a test class may be regarded as 
a "template" for separate instances of itself, which differ from each other only on the basis of 
5 device-specific and/or device-test-specific data. Test classes are specified in the test plan file. 
Each Test class typically implements a specific type of device test or setup for device test. For 
example, an embodiment of the invention may provide a specific implementation of the ITes t 
interface, for example, FunctionalTest, as the base class for all functional tests for DUTs. 
It provides the basic functionality of setting test conditions, executing patterns, and determining 
10 the status of the test based on the presence of failed strobes. Other types of implementations 
may include AC and DC test classes, denoted here as ACParametricTests and 
DCParametricTests. 

All test types may provide default implementations of some virtual methods (e.g., 
init ( ) , preExec ( ) , and postExec ( ) ). These methods become the test engineer's entry 
1 5 points for overriding default behavior and setting any test-specific parameters. However, 
custom test classes can also be used in test plans. 

Test classes allow the user to configure class behavior by providing parameters 
that are used to specify the options for a particular instance of that test. For example, a 
Functional Test may take parameters PList and TestConditions, to specify the Pattern 

20 List to execute, and the Level and Timing conditions for the test, respectively. Specifying 
different values for these parameters (through the use of different "Test" blocks in a test plan 
description file) allows the user to create different instances of a Functional Test. Figure 5 
illustrates how different test instances may be derived from a single test class. These classes 
may be programmed directly in object-oriented constructs, such as C++ code, or designed to 

25 allow a test program compiler to take the description of the tests and their parameters from a test 
plan file and generate corresponding C++ code, which can be compiled and linked to generate 
the test program. A Template Library may be employed as the general-purpose library of 
generic algorithms and data structures. This library may be visible to a user of the tester, so that 
the user may, for example, modify the implementation of a test class to create a user-defined 

4 

30 test class. 

As to user-developed test classes, an embodiment of the system supports 
integration of such test classes into the framework in that all test classes derive from a single 
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test interface, e.g., Uest, so that the framework can manipulate them in the same way as the 
standard set of system test classes.. Users are free to incorporate additional functionality into 
their test classes, with the understanding that they have to use custom code in their test 
programs to take advantage of these additional facilities. 

5 Each test site 1 10 is dedicated to testing one or more DUTs 106, and functions 

through a configurable collection of test modules 1 12. Each test module 1 12 is an entity that 
performs a particular test task. For example, a test module 112 could be a DUT power supply, a 
pin card, an analog card, etc. This modular approach provides a high degree of flexibility and 
configurability. 

1 0 The Module Commands Implementation classes 248 may be provided by module 

hardware vendors, and implement either the module-level interfaces for hardware modules, or 
provide module-specific implementations of standard interfaces, depending on the commands 
implementation method chosen by a vendor. The external interfaces of these classes are defined 
by pre-determined module level interface requirements, and backplane communications library 

1 5 requirements. This layer also provides for extension of the standard set of test commands, 
allowing the addition of methods (functions) and data elements. 

The Backplane Communications Library 249 provides the interface for standard 
communications across the backplane, thereby providing the functions necessary to 
communicate with the modules connected to the test site. This allows vendor-specific module 
20 software to use a Backplane Driver 250 to communicate with the corresponding hardware 
modules. The backplane communications protocol may use a packet based format. 

Tester Pin objects represent physical tester channels and derive from a tester pin 
interface, denoted here as ITesterPin. The software development kit (SDK) of an embodiment 
of the invention provides a default implementation of ITesterPin, which may be called 
25 TesterPin, which is implemented in terms of a predetermined module-level interface, IChannel. 
Vendors are free to make use of TesterPin if they can implement their module's functionality in 
terms of IChannel; otherwise, they must provide an implementation of ITesterPin to work with 
their module. 

■ ♦ 

The standard module interface, denoted here as IModule, provided by the tester 
30 system of the invention generically represents a vendor's hardware module. Vendor-supplied 
module-specific software for the system may be provided in the form of executables such as 
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dynamic link libraries (DLLs). Software for each module-type from a vendor may be 
encapsulated in a single DLL. Each such software module is responsible for providing vendor- 
specific implementations for the module interface commands, which comprise the API for 
module software development. 

5 There are two aspects of the module interface commands: first, they serve as the 

interface for users to communicate (indirectly) with a particular hardware module in the system, 
and second, they provide the interfaces that third-party developers can take advantage of to 
integrate their own modules into the site controller level framework. Thus, the module interface 
commands provided by the framework are divided into two types: 

10 The first, and most obvious, are those "commands" exposed to the user through 

the framework interfaces. Thus, a tester pin interface (ITes terPin) provides methods to get 
and set level and timing values, while a power supply interface (I Power Supply) provides 
methods for powering up and powering down, for example. 

m 

In addition, the framework provides the special category of the predetermined 
15 module-level interfaces, which can be used to communicate with the modules. These are the 
interfaces used by framework classes (i.e., "standard" implementations of framework interfaces) 
to communicate with vendor modules. 

However, the use of the second aspect, the module-level interfaces, is optional. 
The advantage of doing so is that vendors may then take advantage of the implementations of 

20 classes such as ITesterPin and IP owerSupply, etc. while focusing on the content of specific 
messages sent to their hardware by implementing the module-level interfaces. If these 
interfaces are inappropriate to the vendor, however, they may choose to provide their custom 
implementations of the framework interfaces (e.g., vendor implementations of ITesterPin, 
IPowerSupply, etc.). These would then provide the custom functionality that is appropriate for 

25 their hardware. 

With this open architecture as background, the test program development system 
of the present invention is further described as follows. Section A below describes rules to 
describe the test environment in which test program will be used; ; section B describes the 
method and rules for test program development; section C specifies the method and rules to 
30 develop a test plan and how to define the main structure of the test program; section D describes 
how to run a test program on an open architecture test system; section E describes a method and 
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rules for test patterns; section F describes rules to describe the timing of the test patterns; and 
section G describes rules for the overall tester operation. 

A. Components 

The test environment comprises a set of files that specify the necessary 
5 conditions for bringing up the tester, and for preparing it to run a set of tests. The test 
environment preferably includes files for: 

1 . Tester Resource definition: for the specification of the types of tester resources 
— and supported parameters for such resources — that are available in the open 
architecture test system. 

10 2. Tester configuration: for the specification of Site Controllers, sites and 

corresponding mappings. 

3. Module configuration: for specification of the hardware module in each site 

4. Pin descriptions: for naming of DUT pins, such as signal pins, power supplies, 
and to describe pin groups, 

15 5. Socket: for the specification of DUT pin-to-tester pin assignments 

6. Pin options: for the specification of special options, or modes, for pins. 

7. Pattern lists: for the specification of test patterns and their sequence. 

8. Patterns: for the specification of test vectors. 

Of the above, items 1-3 are created by ICF (installation and configuration files) 
20 with information from a CMD (configuration management database), and made available at a 
well-known location, while items 4-8 are user-specified. This section provides descriptions for 
the items 1-6 above; items 7-8 are described in more detail in section E. Specific methods and 
rules are preferably used to develop each of these components; these methods and rules will be 
described in this section with examples. 

25 Al. The Resource Definition 



Each hardware module provides one or more types of hardware resources 
(resources for short) for use by the test system. The tester Resource Definition is preferably 
used to declare a set of resource names for the available resource types, and a set of parameter 

* 

names and types associated with each particular resource type. For instance, the resource name 
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dpin is used to refer to digital tester pins. These resources have parameters such as VIL (for the 
input low voltage), VIH (for the input high voltage), VOL (for the output low voltage), VOH 
(for the output high voltage), etc. A resource definition file will have the extension ".rsc" 
Shown below is an example resource definition, containing some tester resources: 
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# File Resources jsc 
# 

Version 0. 1 .2; 
5 ResourceDefs 

{ 

# digital pins 
dpin 

{ 

10 # Low and High voltages for input pins 

Voltage VOL, VIH; 

* 

# Low and High voltages for output pins 
Voltage VOL, VOH; 

} 

15 # power supplies 

dps 

{ 

# 

# PRE_WATT specifies the time to wait after voltage 
20 # reached its final value to start pattern 

# generation. The actual time that the system 

# will wait is a small system specified range: 

# PRE JVAIT-delta <= actual <= PRE JVAIT+delta 
# 

25 # PRE^WAITJVDLN is a minimum amount to wait after voltage 

# reached its final value to start pattern generation. 

# It is a system specified range: 

# PRE_WAU_MIN <= actual <= PRE_WAIT_MIN+delta 
# 

30 # POST_WAIT specifies the time to wait after pattern 

# generation ends to shut down the power. The actual 

# time that the system will wait is a small system 

# defined range: 



WO 2004/072670 



17 



PCT/JP2004/001649 



# POST_WAIT-delta <= actual <= POST_WAIT+delta 
# 

# POST_WAJT_MIN specifies the time to wait after pattern 

# generation ends to shut down the power. The actual 
5 # time that the system will wait is a small system 

# defined range: 

# POST_WAIT_MIN <= actual <= 
POST_WATT_MIN+delta 

# 

10 Time PRE_WAIT; 

Time PRE_WAIT_MIN; 
Time POST_WAJT; 
Time POST_WAIT_MIN; 

# The voltage. 

15 Voltage VCC; 

} 

} 

Note that the type of a resource parameter (such as Voltage or Time) is 
preferably a standard engineering unit Vendors supplying special purpose resources that prefer 
20 the specification of different parameters should provide their own resource definition files. 

Structure for the Resource Definition 

Given below is a structure for the resource definition file in accordance with a 
preferred embodiment of the present invention: 

resource-file: 

25 version-info resource-defs 

version-info: 

i 

Version version-identifer ; 



resource-defs: 

ResourceDefs { resource-def-list } 
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resource-def-list: 
resource-def 

resource-def-list resource-def 

* 

resource-def, 

5 resource-name { resource-params-decl-list } 

resource-params-decl-list: 
resource-params-decl 

resource-params-decl-list resource-params-decl 

resource-params-decl : 
1 0 elementary-type-name resource-param-name-list ; 

resource-param-name-list: 
resource-param-name 

resource-param-name-list , resource-param-name 

Undefined non-terminals above are specified below: 

1 5 1 . version-identifier: A sequence of one or more characters from the set 

[0-9a-zA-Z.] . It represents a version number. 

2. resource-name: A sequence of one or more characters from the set [a- 
zA-ZJ)-9], not starting with a digit. It represents the name of a 
resource, such as dpin or dps. 

20 3 . elementary-type-name: A sequence of one or more characters from the 

set [a-2A-Z_0-9], not starting with a digit. It represents the name of an 
elementary type, such as Voltage (cf.). 

4. resource-param-name: A sequence of one or more characters from the 
set [a-zA-ZJ)-9], not starting with a digit. It represents the name of a 
25 resource parameter, such as VIL. 



A2. Tester Configuration 
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The The Tester Configuration is a set of rules that is preferably used to list the 
Site Controllers in a particular system configuration, and the connection of the Site Controllers 
to the Switch Matrix input ports. In the architecture of an embodiment of the invention, a single 
Site Controller can be connected to a single switch matrix input port Thus, in. this context, the 
5 switch matrix connections serve as implicit identifiers for the Site Controllers in the system 
(other configurations are possible). The following is an example of a typical tester 
configuration: 



# 

# Tester Configuration, Sys.cfg 
10 # 

Version 1.2.5; 

SysConfig 

{ 

# 

15 # The first field is the hostname of the Site Controller machine; 

#it can be specified as either a dotted-decimal IP address or a 

# domain-qualified hostname. 

# 

# The second field is the switch matrix input port number, which 
20 # implicitly serves as the identifier for the Site Controller 

# connected to it. 
# 

zeus.olympus.deities.org 2; 
127.0.0.2 4; 
25 127.0.0.0 1;#SITEC-1 

127.0.0.3 3; 

} 

The system configuration for a particular test-floor system is part of the system 
profile, and is made available as the system configuration file Sys.cfg. Note that in one 
30 embodiment the Site Controller connected to port 1 ("127.0.0.0" in the above example) may 
enjoy special status, in which it alone configures the Switch Matrix. This "special" Site 
Controller will be referred to as SITEC-1. Also note that the site controller address in this 
example is an IP address because the site controllers may be connected to the system controller 
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by an internal network. Conversely, the system controller may be connected to an external 
network to access files, such as pattern data. 

Structure for the Tester Configuration 

Given below is a structure for the system configuration file in accordance with an 
5 embodiment of the present invention: 

system-config-file: 

version-info system-config 

version-info: 

Version version-identifer ; 

10 system-config: 

SysConfig { site-controller-connection-list } 

site-controller-connection-list: 
site-controller-connection 

site-controller-connection-list site-controller-connection 

15 site-controller-connection: 

site-controller-hostname input-port ; 

site-controller-hostname: 
ip-address 

domain-qualified-hostname 

20 ip-address: 

octet . octet . octet . octet 

domain-qualified-hostname: 
name 

domain-qualified-hostname . name 
25 Undefined non-terminals above are specified below: 

1 . version-identifier: A sequence of one or more characters from the set 
[0-9a-zA-Z.]. It represents a version number. 

* 

2. octet: A nonnegative integer from 0 to 255 (in decimal notation). 
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3. name: A sequence of one or more characters from the set [a-zA-Z_0-9], 
not starting with a digit. It represents a name segment in a domain- 
qualified hostname. 

4. input-port: A nonnegative integer, in decimal notation. 



A3. The Module Configuration 

The Module Configuration allows the specification of the physical configuration 
of the tester, e.g., the physical location and type of each module in a SYSTEM chassis. This is 
necessitated by the dynamic nature of the tester bus configuration, which allows a mapping of 
the tester bus address to the physical slot location. This information allows a hardware 
discovery process that occurs at system boot-up time to validate the SYSTEM configuration. 
Each output port of the Switch Matrix defines a physical slot, which is preferably occupied by a 
single hardware module. Shown below is an example of a module configuration specified in the 
file Modules.cfg in accordance with an embodiment of the invention: 



# 

# Module Configuration File, Modules.cfg 
# 

Version 0.0.1; 

ModuleConfig 
{ 

# 

# A configuration definition which provides information about 

# the module type that is attached to slots 1-12 and 32-48. 

# Note that a module might provide more than 

# a single type of resource. 
# 

Slot 1-12, 32-48 # Switch matrix output ports 

# which use the configuration 

# defined below. 

{ 
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10 



15 



20 



25 



30 



} 

# 



VendorlD 1; # defined vendor code. 

ModulelD 1; # Vendor-defined id code. 

ModuleDriver modi .dll; # Module software. 

# 

# Resource named dpin specifies channels 

# for digital data. The name dpin is not 

# a keyword. It is simply the name of a hardware 

# resource, and is obtained from the resource 

# definition file. 
# 

Resource dpin 

{ 

MaxAvailable 32; 

} 



# Resource units 1 32. 



Resource analog 

{ 

MaxAvailable 16; 
Disabled 1-8; 



# Resource units 1 .. 16. 
# Disabled resources 1 .. 8. 

# So, enabled ones are 9 .. 16. 



} 



# A configuration definition which provides information about 

# the module type that is attached to slots 16-30, 50, and 61-64. 
# 

Slot 16-30, 50,61-64 
{ 

Resource dpin 

{ 

MaxAvailable 32; # Max available resource units. 

Disabled 3, 30-32; # Disabled resources. 

} 



ModuleDriver "module two.dll"; 
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VendorlD 2; 
ModuleED 2; 

} 

# 

5 # A configuration definition, which provides information about 

# the module type that is attached to slots 65-66. 
# 

Slot 65-66 
{ 

10 ModuleED 4; # DPS module with 8 supplies. 

ModuleDriver mod4.dll; 
VendorlD 1; 

# 

# Resource type dps specifying resource units for a 
15 # Device Power Supply 

# 

Resource dps 

{ 

MaxAvailable 4; 

20 Disabled 1; 

} 

} 

} 



25 As mentioned earlier, in one embodiment a slot refers to connector through 

which a hardware module can be connected, such as an output port of the switch matrix. Each 
configuration definition provides information about the module that may be attached to one or 
more slots. The VendorlD specified in a configuration definition is a unique ID associated with 
a vendor. The ModulelD refers to a type of module provided by this vendor. There may be 

30 several instances of the same ModulelD in a tester configuration. The ModuleDriver refers to a 
vendor supplied DLL to service the module. Finally, the Resource refers to the units serviced 
by this module, and provides a name for the resource type; the resource name is obtained from 
the resource definition file. 
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The above example describes three configuration blocks in a module 
configuration file. In one implementation, the first configuration block, slots 1 - 12 and 32 - 48 
are serviced by a module produced by vendor 1. This vendor provides the module, the identifier 
"1" to refer to this module type, and the module driver library to control the module. This 
5 module can provide two types of resource units, one designated by the resource name "dpin", 
with preferably a total number of 32 resource units (i.e., "channels"), all of which are available, 
and the other designated by the resource name "analog", with a total number of 16 resource 

• * 

units, of which only 9 through 16 are available. The second and third configuration blocks are 
specified in a manner similar to the first configuration. 

1 0 Note that the provision for allowing channels to be denoted as "disabled" is to 

allow for the identification of defective resource units on modules that are still functional 
otherwise. Note also that a configuration block may have one or more slot identifiers. When a 
block has more than a single slot identifier, then the identified slots are said to be cloned. 

The module configuration file, Modules.cfg, is created as part of the system 
1 5 profile by the ICM (installation configuration management system) (with test-floor-specific 
information provided by the user), and made available at a well-known location. The ICM is a 
utility that can be local to the test system, e.g., on the system controller, or reside elsewhere on 
the network to which the system controller is connected. The ICM manages the CMD 
(configuration management database), and typically updated on hardware changes to the system 
20 configuration. ICM allows the user to configure the system, e.g., site controllers and modules. 
The CMD is a database that stores the configurations. For actual tester configuration/operation 
ICM generates the configuration files, e.g., module configuration, and other files, and copies 
them and associated files, such as particular module DLLs, onto the tester. 

Structure for Module Configuration 
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Below is the module configuration structure in accordance with the preferred 

embodiment: 
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file-contents: 

version-info module-config-def 

version-info: 

Version version-identifier ; 

module-config-def: 

ModuleConfig { slot-entry-list } 

slot-entry-list: 
slot-enUy 

slot-entry-list slot-entry 

slot-entry: 

Slot positive-integer-list { slot-info } 

slot-info: 

required-config-list 

required-config-list: 
required-config 

required-config-list required-config 

required-config: 

VendorED id-code ; 
ModulelD id-code ; 
ModuleDriver file-name ; 

Resource resource-name { max-spec disabled-spec opt } 

max-spec: 

MaxAvailable positive-integer ; 

disabled-spec: 

Disabled positive-integer-list ; 

positive-integer-list: 

positive-integer-list-entry 
positive-integer-list , positive-integer-list-entry 

positive-integer-list-entry: 
positive-integer 
positive-integer-number-range 
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positive-integer-number-range: 
positive-integer - pos-integer 

Undefined non-terminals above are described below: 

■ 

1 . version-identifier: A sequence of one or more characters from the set 
[0-9a-zA-Z.], where the first character must be from the set [0-9], 

2. positive-integer: A sequence of one or more characters from the set [0- 
9], not starting with a 0. 

3 . id-code: A sequence of one or more characters from the set [a-zA-Z_0- 

4. resource-name: A sequence of one or more characters from the set [a- 
zA-Z_0-9], where the first character must be from the set [a-zA-Z]. 

Comments are supported; comments start with the character, and extend to 
the end of the line. 

A4. Pin Descriptions 

The DUT pin descriptions are described using a Pin Descriptions file. The user 
makes available a description of the DUT pins in a pin description file, which has the 
extension .pin. This plain text file contains, at least the following: a listing of the DUT pin 
names; and initial definitions of named pin groups, which make use of the defined DUT pin 
names ("initial" since they can be subsequently modified or added to, etc., programmatically). 

The separation of this data specification from the Test Plan description allows 
general reuse of the DUT pin definitions, and allows the pattern compiler to derive pin names 
(required for resolving references to pin names used in vector specifications) from the pin 
description file, without having the process tied to a specific Test Plan. 

Shown below is an example pin description file: 
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# 

# Pin description file, myDUT.pin. 
# 

# Note that this implicitly imports the resource 

# configuration file,Resources.rsc. 
# 

Version 1.1.3a; 



PinDescription 

{ 

1 0 Resource dpin 

{ 

AO; 
Al 
A2 

15 A3 

A4 

# This syntax expands to the names "ABUS[1]" and "ABUS[2]" 
ABUS[1:2]; 

A5; 

20 BBUS[1:8]; 

DIR; 

CLK; 

Group Grpl 
{ 

25 DIR CLK, AO, Al , A2, A3, A4, BBUS[1 :4] 

} 
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Group Gip2 
{ 

A5, 
# 

# The following line will expand to 
#"DIR, Al, A2, A4, A5, BBUS[2] ": 

GtoI - CLK - AO - A3 - BBUS[1] - BBUS[3:4] + A5, 
BBUS[5:8] 

} 

} 

Resource dps 

{ 

vccl; 
vcc2; 
vcc3; 

Group PSG 

{ 

vccl, vcc2 

} 

} 

} 

Note that the DUT pin and pin group definitions are encapsulated within resource 
type blocks, to allow the compiler to correlate pin and pin group definitions with the allowable 
parameter settings for Levels, etc. 

The following points about pin descriptions should be noted: 

1 . Pin groups and pins share the same namespace and have global (i.e., Test Plan) 
scope. One of the consequences of the global scoping of these names is that pins 
and pin groups cannot use duplicated names, even when declared in different 
resource blocks. 

2. At least one Resource definition is required in the pin description file. 
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3 . At least one pin name should be defined in each resource. 

4. Pin and group names are required to be unique within resource boundaries. 

5. The same pin or group name can be defined for two or more resources. However, 
duplicates within the same resource are ignored. 

6. All pin names and group names that appear in a group definition should have been 
already defined within that resource. 

7. Group definitions, if given, should have at least one pin name or group name (i.e., a 
group definition cannot be empty). 

8. A pin group definition can include a reference to a previously-defined pin group. 

9. A pin group definition can include set operations such as addition and subtraction of 
previously defined pins and/or pin groups. 

Structure for the Pin Descriptions 

■ • 

Given below is the structure for the pin descriptions in accordance with the 
preferred embodiment of the present invention: 
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l 

pin-description-file: 

version-info pin-description 

version-info: 

Version version-identifer ; 

pin-description: 

PinDescription { resource-pins-def-list } 

resource-pins-def-list: 
resource-pins-def 

resource-pins-def-list resource-pins-def 

resource-pins-def: 

Resource resource-name { pin-or-pin-group-def-list } 

pin-or-pin-group-def-list: 
pin-or-pin-group-def 

pin-or-pin-group-def-list pin-or-pin-group-def 

pindefor-pin-groupdef: 
pin-def ; 
pin-group-def 

pin-def: 
pin-name 

pin-name [ index : index ] 

pin-group-def: 

Group pin-group-name {pin-group-def-item-list } 

pin-group-def-item-list: 
pin-def 

pin-group-def-item-list , pin-def 

Undefined non-terminals above are specified below: ^ 

1 . version-identifier: A sequence of one or more characters from the set 
[0-9a-zA-Z.]. It represents a version number. 



WO 2004/072670 



31 



PCT/JP2004/001649 



2. resource-name: A sequence of one or more characters from the set [a- 
zA-Z_0-9] not starting with a digit. It represents the name of a resource, 
such as dpin or dps. 

3. pin-name; A sequence of one or more characters from the set [a-zA- 
ZJ)-9] not starting with a digit. It represents the name of a pin AO. 

4. pin-group-name: A sequence of one or more characters from the set [a- 
zA-Z_0-9] not starting with a digit. It represents the name of a pin 
group ABUS. 

5. index: A nonnegative integer. It represents the lower bound or an 
upper bound on a group of related pins. 

A5. The Socket 

The Socket specifies the mapping between DUT pin names and physical tester 
pin (channel) assignments (the physical tester channel numbers are defined in the module 
configuration file). Note that different Sockets can be used to support different DUT packages 
and different load board configurations, etc. For a multi-DUT system, the Socket definitions for 
DUT/channel assignments can support "cloning" of a basic Socket to multiple sites. However, 
different Sockets (i.e., different physical mappings for the same logical pins) should respect site 
module partitions. Thus, in addition to providing DUT pin to tester channel assignments, the 
socket also effectively defines the site partitioning. A Socket file could thus contain definitions 
for several individual site sockets. Shown below is a sample socket file defining three DUT 
sites: 

Version 1.1.3 

SocketDef 
{ 

DUTType Pentium3 
{ 

PinDescription dutP3.pin; # The pin description file for Pentium3 

DUT 2 # Uses the full-specification syntax 
{ 

SiteController 1; # Switch Matrix input port 
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Resource dpin 

{ 

# 

# The CLK pin is assigned to resource dpin, 

# slot 2, resource unit (channel) 13. 
# 

CLK 2.13; 
# 

# The D1R pin is assigned to resource dpin, 

# slot 5, resource unit 15. 
DIR. 5.15; 

# 

# The following statement will be expanded to 

# BBUS[7] 5.4 

# BBUS[6] 5.5 

# BBUS[5] 5.6 
# 

# So for example, the pin sequence BBUSt7], BBUS[6], 

# BBUS[5] is assigned to the same slot 5, and to 

# resource units 4, 5 and 6 respectively. 
# 

BBUS[7:5] 5.[4:6]; 

BBUS[1:4] 7.[21:18]; 
BBUS[8] 9.16; 

} 

Resource dps 
{ 

# 

# The VI pin is assigned to resource dps, 

# slot 1, resource unit (channel) 1 . 
# 

VCC1 1.1; 
# 
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# The VCC2 pin is assigned to resource dps, 

# slot 1, resource unit (channel) 2. 
# 

. VCC2 1.2; 
} 

} # End DUT 2 

DUT 1 # This is "cloned" from DUT 2 above 
{ 

SiteControIler 1 ; # Same Site Controller as for DUT 2 

Resource dpin 
{ 

SlotOffset 1 ; # Offset value for slots 

} 

Resource dps 

{ 

SlotOffset 10; # Offset value for slots 

} 

# 

# The offset syntax above indicates that the slot/resource 

# unit assignments are "cloned" from the first DUT defined 

# for this DUTType, i.e., DUT 2, with the slots offset by 

# the SlotOffset values. 
# 

# Looking at the definition of dpin resource units for 

# DUT 2, CLK is bound to slot 2. Hence, for the present 

# DUT, CLK is bound to slot 2 + 1 = 3. 
# 

# Some of the new bindings in effect due to the offset 

# assignments are shown in the table below: 
# 

# 

# Pin Resource RUnit Slot 

# ; 
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# CLK dpin 13 2+ 1 

= 3 

# DIR dpin 15 5+1 

= 6 

# BBUS[8] dpin 16 

# VCC1 dps 1 

# VCC2 dps 2 

} # End DUT 1 

} # End DUTType Pentium3 

DUTType 74LS245 
{ 

PinDescription dutLS.pin; 

DUT 3 disabled # This DUT site is disabled, and will be ignored 
{ 

m 9 m 

} 

} # End DUTType 74LS245 
} # End SocketDef 

The following points about a Socket file should be noted: 

1 . The Socket file uses information from both module configuration file, 
and the user's pin description files for the given DUT types (see 
specification for PinDescription in the example above). The module 
configuration information is made implicitly available to the Socket file 
compiler. The socket file compiler is a sub-part of the pattern compiler 
that reads and analyzes the socket DUT name to tester channel mapping, 
and the module configuration and pin description files to set up the 
mapping of tester pins to DUT pins used by the pattern compiler. 

2. At least one DUT site definition per DUT type is required, and it must 
use the full-specification syntax, as opposed to the SlotOffset syntax. If 



9+ 1 = 10 
1 + 10=11 
1 + 10=11 
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more than one DUT site definition is provided for the same DUT type, 
the first one must use the full-specification syntax. 

3. Each subsequent DUT site definition (for the same DUT type) may use 
either the full-specification syntax or the SlotOffset syntax, but not both. 

5 This allows individual sites to deviate from a standard pattern (due to, 

for example, inoperative channels). 

4. The bindings derived from the SlotOffset syntax are defined relative to 
the first site defined for that DUT type (which uses the foil- 
specification syntax). 

10 5, DUT sites do not need to be declared in the actual physical order. This 

allows a case where the first (physical) site deviates from the pattern. 

6. The DUT site IDs are required to be unique across the entire Socket 
(i.e., across all DUT types defined therein). 

7. At least one resource definition is required per DUT site definition. 

15 8. The site definitions must be used in conjunction with the module 

configuration to determine if the test configuration is single-site/single- 
DUT or single-site/multi-DUT. 

9. Li all cases, the Socket file should specify a set of DUT channel 
mappings which are consistent with the pin description file and the 

20 module configuration file. 

10. in some cases, it will be desirable to allow the Socket definition to 
specify that one or more DUT channels are disconnected from the tester 
(for example, by designating the assigned physical channel as one with 
the special ID "0.0"). In this case, these DUT channels may be used 

25 and referenced in the context of the test program. Operations on such 

channels will result in system warnings (but not errors.). At load time, 
pattern data for disconnected channels will be discarded. 



Structure for the Socket 
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Below is the structure for the module configuration in accordance with a 
preferred embodiment of the present invention: 

socket-file: 

version-info socket-def 

version-info: 

Version version-identifer ; 

socket-def: 

SocketDef { device-specific-socket-def-list } 

device-specific-socket-deflist: 
device-specific-socket-def 

device-specific-socket-def-list device-specific-socket-def 

device-specific-socket-def: 

DUTType DUT-type-name {pin-description-file dut-info-list } 

pin-description-file: 

PinDesc pin-description-file-name ; 

dut-info-list: 
dut-info 

dut-info-list dut-info 
dut-info: 

DUT dut-id { site-controller-input-port resource-info-list } 

site-controller-input-port: 

SiteController switch-matrix-input-port-number ; 

resource-info-list: 
resource-info 

resource-info-list resource-info 
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resource-info: 

Resource resource-name { resource-item-unit-assignment-list } 

5 resource-item-unit-assignment-list: 

resource-item-unit-assignment 

resource-item-unit-assigfiment-listresource-item-unit-assignmen^ 

resource-item-unit-assignment: 
1 0 resource-item-name slot-number . resource-unit ; 

resource-item-name [ resource-item-index ] slot-number . resource- 
unit-index ; 

resource-item-name [ resource-item-index-range ] \ 
slot-number . [ resource-unit-index-range ] ; 



15 



resource-item-index-range: 

resource-item-index : resource-item-index 



resource-unit-index-range: 
20 resource-unit-index : resource-unit-index 

Undefined non-terminals above are specified below: 

1 . version-identifier: A sequence of one or more characters from the 
set [0-9a-zA-Z.]. It represents a version number. 

2. DUT-type-name: A sequence of one or more characters from the 
25 set [0-9a-zA-Z.], where the first character must not be from the set [0-9]. 

It represents a type of DUT, such as Pentium3. 

3. pin-description-file-name: The simple name of a file, not including 
its directory name, but including all extensions. The filename is of the 
syntax recognized by the host operating system, and allows blanks and 

3 0 other characters if enclosed in quotes. 

4. switch-matrix-input-port-number: A nonnegative integer in decimal 
notation to represent the port number of the input port connected to the Site 
Controller. 
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5 . dut-id: A nonnegative integer in decimal notation to identify an 
instance of a DUT. 

6. resource-name: A sequence of one or more characters from the set 
[0-9a-zA-Z.], where the first character must not be a digit. It represents the 

5 name of a resource defined in a resource file. 

7. resource-item-name: A sequence of one or more characters from . 
the set [0-9a-zA-Z.], where the first character must not be a digit. It 
represents the name of a resource unit, such as a pin or a pin group. 

8. resource-item-index: A nonnegative integer in decimal notation that 
1 0 represents a particular member of a group of resource items. When in the 

context of a resource-item-index-range it represents the lower or upper 
bound of a contiguous sequence of resource item group. 

9. resource-unit-index: A nonnegative integer in decimal notation that 
represents a particular member of a group of resource units (channels). 

1 5 When in the context of a resource-unit-index-range it represents the lower 

or upper bound of a contiguous sequence of resource unit group. 

■ 

A6. Pins 

Note that in addition to logical pin name to physical channel mappings (as 
20 provided by the Socket), several attributes can be used for specifying the tester resources. For 
example, options might be used to define particular hardware configurations for channels, which 
may be test-specific, vendor-specific, and/or test system-specific. These will be described using 
the Pin Mode Options, and made available via a Pin Mode Options file. 

A Pin Mode Option definition would support the configuration of special options 
25 or modes for a tester channel. This could, for example, be used to select and configure channel 
multiplexing. It is preferred that the Pin Mode Option only be used as part of a Test Plan 
initialization flow, since it might require significant channel configuration. The Pin Option 
syntax supports vendor-defined options. An example is shown below: 
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PinModeOptions 
{ 

clock IN double; 
aO OUT single; 

5 

}; 

Test Environment Configuration 

As pointed out earlier, the resource definition file (Resources.rsc), the system 
1 0 configuration file (Sys.cfg) and the module configuration file (Modules.cfg) are preferably 
made available at a "well-known" location. This "well-known" location is the directory 
specified by the value of the system environment variable Tester_ACTIVE_CONFIGS. For 
example, if the value of Tester_ACTIVE_CONFIGS is the directory F:\Tester_SYS\configs, 
the system will expect the following files to be present: 

1 5 F:\TesterJSYS\configs\Resources.rsc 
F:\Tester_SYS\configs\Sys.cfg 
F:\Tester_SYS\configs\Modules.cfg 

During installation, the Installation and Configuration Management system 

20 (ICM) residing on the host computer will preferably set the value of 

Tester_ACTIVE_CONFIGS . Every time the ICM creates a new version of one of the above 
files, it will place the new version in the location pointed to by Tester_ACTIVE__CONFIGS. 
Note that in addition to the above three files, other system configuration files such as the 
simulation configuration file are also placed in the location pointed to by 

25 Tester_ACTIVE_CONFIGS 

B. Rules for Test Program Development 
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One of the two principal end-user oriented components of the tester system is the 
test environment. The other component is the programming facility that the tester makes 
available for the end user (i.e., test engineer and test class developers). 

The principal component of the programming environment is the test plan. The 
test plan uses test classes (which are different implementations of a test interface denoted Test), 
which realize the separation of test data and code for particular types of tests. 

The plan may be written directly as a C++ test program, or described in a test 
plan description file, which is processed by a Test Program Generator (translator 402) to 
produce object-oriented code, such as C++ code. The generated C++ code can then be compiled 
into the executable test program. The data required for populating a test class instance, such as 
levels, timings, etc., are specified by the user in the test plan description file. 

A test program contains a set of user written files that specify details for running 
a test on a device. An embodiment of the invention includes sets of rules that permit a user to 
write these files using C++ constructs. 

One of the requirements according to the embodiment of the invention is to 
follow the modularity of the open architecture test system.. A modular development permits 
users to write individual components dealing with different aspects of the test, and then permits 
these components to be mixed and matched in various ways to yield a complete test program. A 
test program in accordance with the preferred embodiment of the present invention comprises a 
set of files as follows: 



files *.usrv for user variables and constants) 

files *.spec for specification sets; 

files *.lvl for levels; 

files *.tim for timings; 

files *.tcg for test condition groups; 

files *.bdefs for bin definitions; 



files *.ph for a pre-header, files for custom functions and test classes. 



WO 2004/072670 PCT/JP2004/001649 

41 

* 

files *.ctyp for custom types; 

files *.cvar for custom variables;.md 

files *.tpl for test plans. 

5 The file extensions above are a recommended convention facilitating 

categorization of files. A single test program will preferably comprise a single test plan file, and 
the files it imports. An "import" refers to other files with data that is either directly referenced 
by the importer (the file that specifies the import), or is imported by some other file directly 
referenced by the importer. The test plan file could define globals, flows, and other such objects 
10 within it, or it could import this information from other files. These rules allows any of the 
above components to be either in their own individual files, or directly inlined into a test plan 
file. Note that the test plan is similar in concept to a C-language mainO function. 

Test Program Features 

User Variables and Constants, 
15 Specification Set, 
Levels, 
Timings, 

i 

Test Conditions 
Bin Definition 
20 Pre-Headers 
Custom Types 
Custom Variables 
Test Plan 
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Test program identifiers preferably start with an upper or lower case alphabetical 
character, and can subsequently have any number of alphabetical, numerical, or underscore (_) 
characters. It has several keywords which are provided in the description given below. These 
keywords are visually identified in code in this document using a bold font, such as Version. 
5 Keywords are reserved, and preferably not be used as identifiers. There are several special 
symbols such as {, }, (, ), :, and others which are described below. 

Elaboration of Test Objects 

An import of a test description file enables the importing file to refer to names of 
objects made available by the imported file. This allows the importing file to reference the 
10 objects named by the imported file. Consider a socket file aaa.soc that imports a pin description 
file xxx.pin. There could be another bbb.soc file that also imports xxx.pin. However, neither of 
these imports cause the objects described by xxx.pin to come into existence. They merely 
reference objects that are already assumed to exist 

The question arises: when do such objects come into existence? This is where 
15 the Test Plan file is fundamentally different. In an analogy to C, it would be a file with a mainO 
routine in it. An "Import" statement in test plan file will elaborate these objects, that is, cause 
these objects to come into existence. The test plan mickey .tpl shown below causes the objects 
in xxx.pin and aaa.soc to be elaborated: 

# File for Mickey' s TestPlan 
20 Version 3.4.5; 



# 

# These import statements will actually cause the 

# objects to come into existence: 
25 # 

Import xxx.pin; # Elaborates pin and pin-group objects 
Import aaa.soc;# Elaborates site socket map objects 

# Other imports as necessary 
... 

30 Flow Flowl 

{ 

... 
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} 

An import of xxx.pin in the test plan causes all the pin and pin group objects 
declared in xxx.pin to be elaborated. This is described as follows: "the file xxx.pin is 
elaborated". It is not necessary for a Test Plan to directly import all the files that need to be 
5 elaborated. A file x is imported by a file y if either of the two statements below is true: 

1 . y has an import statement that names x; or 

J 2. x is imported by z, and y has an import statement naming z. 

When a test program is compiled, it will elaborate all the objects in the files that 
10 are imported by the test plan. The set of files imported by a test plan are topologically sorted to 
yield an order in which the files are elaborated. The set of files imported by a test plan is 
referred to as the import closure of the test plan. If the import closure of a test plan cannot be 
topologically sorted, then there must be an imports cycle. Such a situation is erroneous, and 
will be rejected by the compiler. 

1 5 User Variables and Constants 

Global variables and constants will be defined using the User Variables and 
Constants. . Constants are objects whose value is bound at compile time, and cannot be 
changed. The maximum integer value, for instance, would be a constant. On the other hand, 
the expression bound to variables can change at runtime via an API. 

20 Integer, 

Unsignedlnteger, 

Double, 

String, 

Voltage in Volts (V), 
25 VoltageSlew in Volts per Second (VPS), 



Current in Amps (A), 
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Power in Watts (W)> 
Time in Seconds (S), 
Length in Meters (M), 
Frequency in Hertz (Hz), 

« 

5 Resistance in Ohms (Ohms), and 
Capacitance in Farads (F). 

The types Integer, Unsignedlnteger, Double, and String are referred to as Basic 
Types. The Basic Types have no measurement units. The Elementary Types which are not 
10 basic types are a Double, with an associated measurement unit and a scale. The scaling symbols 
are common engineering scaling symbols: 

p (pico) for 10-12, as in pF (pico-farad) 
n (nano) for 10-9, as in nS (nano-second) 
u (micro) for 10-6, as in uS (micro-second) 
15 m (milli) for 1 0-3 , as in mV (milli-amp) 
k (kilo) for 10+3, as in kOhm (kilo-ohm) 
M (mega) for 10+6, as in MHz (mega-hertz) 

G (giga) for 10+9, as in GHz (giga-hertz) 

A separate file with user variables and constants will have the extension .usrv. 
20 Below is an example of a file with some global constants. An example of a file with some 
variables is given later. 

# — — 

# File limits.usrv 

# 
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Version 1.0.0; 



# 

# This UserVars collection declaration declares a set of 

# globally available variables and constants. 
# 

UserVars 

{ 

# Some constant Integer globals used in various places. 
Const Integer Maxlnteger = 2147483647; 
Const Integer Minlnteger = -2 147483 648; 

# Smallest value such that 1.0 + Epsilon != 1.0 
Const Double Epsilon = 2.22044604925031 3 le-01 6; 

# Some important constants related to Double 

Const Double MaxDouble = 1 .797693 1 348623 1 58e+308; 
Const Double MinDouble = - MaxDouble; 
Const Double ZeroPlus = 2.2250738585072014e-308; 
Const Double ZeroMinus = - ZeroPlus; 



} 



The set of UserVars declared above are considered definitions of the variable on 
the left of the *=\ As a result, a single occurrence of the definition of a variable or constant is 
preferred, and it should be initialized. 

As mentioned earlier, constants should not be changed once they are defined. 
The expression bound to a constant can involve previously defined constants and literal values. 
Variables, on the other hand, can be changed via an API. The expression bound to a variable 
can involve previously defined variables, constants and literal values. 

Each variable is bound to an expression object which is maintained at runtime. 
This provides the capability of changing the expression associated with a variable at runtime, 
and then reevaluating all the variables. The expression object is a parsed form of the right hand 
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side of a variable or constant definition. In one embodiment, no facility is provided for the 
changing of constants at runtime. Their value is preferably fixed at compile time. 

Any number of such files with globals can exist in the import closure of a test 
plan. While the above globals file is a set of numeric limits, here is a set of engineering globals 
using engineering measurement units, and some random user variables: 



# 



# File myvars.usrv 
# 



Version 0.1; 
# 

# This declares a UserVars collection of some engineering 

# globals. 
# 

UserVars MyVars 
{ 

# Engineering quantities. 

Const Voltage VtaLow = 0.0; # 0 Volts 

Const Voltage VlhHigh = 5.0; #5 Volts 

Const Voltage VOutLow = 400.0 mV; # 400 milliVolts 
Const Voltage VOutHigh = 5.1; #5.1 Volts 

Const Time DeltaT = 2 .OE-9; # 2 nanoseconds 

Const Time ClkTick = 1 .0ns; # 1 nanosecond 

Const Resistance R10 = 10.0 kOhms; # 10 kilo Ohms 

# Some variables are declared below. 

Current ILow = 1 .0 mA; # 1 milliAmp 

Current Effigh = 2.0 mA; # 2 milliAmp 

Power PLow = ILow * VInLow; # Low power value 

Power PHigh = Effigh * VlhHigh; # High power value 



# 

#An array of low values for all A bus pins 
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# The vil for AO will be in ABusVil[0], for Al 

# in ABusVil[l], and so on. 
# 

Voltage ABusVil[8] = {1.0, 1.2, Others = 1.5}; 

5 } 

The compiler preferably checks that units and types match up. Note that since a 
Voltage times a Current yields a Power, the equations for PLow and PHigh above will compile. 
However, a statement such as the following will typically not compile: 

10 # 

# Does not compile because a Current and a Voltage cannot be added 

# to yield a Power. 
# 

Power Pxxx = IHigh + VInHigh; 

1 5 The compiler will allow certain automatic type conversions: 

Power Pxxx = 2; # Set the power to 2.0 watts 

Integer Y = 3 . 6; # Y gets assigned 3 

Power Pyyy = Y; # Pyyy gets assigned 3 .0 watts 

Double Z = Pyyy; # Pyyy gets converted to a unitless Double 

20 Explict type conversion to Double, Unsignedlnteger and Integer is also 

permitted: 

Power Pxxx = 3.5; 

# Explicit type conversion is allowed, but not required. 
25 #X becomes 3.5 

Double X = Double(Pxxx); #X becomes 3.5 
Integer Y = Integer(Pxxx); # Y becomes 3 

Conversion between unrelated types is also possible, by converting to an 
intermediate basic type: 

30 Power Pxxx = 3.5; 



# Explicit type conversion is required. 
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Length L = Double(Pxxx); # L becomes 3.5 meters 
Voltage V = Integer(Pxxx);# V becomes 3.0 Volts. 

The TestPlan object provides a UserVars class which is a collection that contains 
names and their associated expressions, values, and types. User variables can go into a Default 
5 User Variables Collection, or into a Named User Variables Collection. The UserVars 

declarations in the example above, which have no specified name, go into tins default collection. 
However, it is possible to explicitly name a collection as follows: 

# Declare X and Y in the MyVars UserVars collection. 
UserVars MyVars 

10 { 

Integer X = 2.0; 
# 

# Refers to the above X, and to the globally 

# available Maxlnteger from the default 
15 # UserVars collection. 

# 

Integer Y = Maxlnteger - X; 

} 

# Declare X, Yl and Y2 in the YourVars UserVars collection. 
20 UserVars YourVars 

{ 

Integer X= 3.0; 

# Refers to the X from MyVars. 
Integer Yl = Maxlnteger - MyVars.X; 

25 # Refers to the X declared above. 

Integer Y2 = Maxlnteger - X; 

# More variables being added to the MyVars collection 
UserVars MyVars 

30 { 

# 

# Refers to X and Y from the earlier declaration 
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# of MyVars. 
# 

* 

Integer Z = X + Y; 

} 

5 Name resolution within a UserVars collection proceeds as follows: 

If a name is qualified — i.e., a name comprises two segments separated by a dot — then 
the variable comes from a named user variables collection, named by the segment that 
precedes the dot. So, MyVars.X above refers to the X in the MyVars collection. The 
name "_UserVars" can be used to explicitly denote the default user variables collection. 

10 If the name is not qualified, and there is a constant or variable of the same name 

in the present collection, then the name resolves to that constant or variable. 

Otherwise, the name resolves to a constant or variable in the default user 
variables collection. 

Evaluation of a block of definitions in a UserVars collection can be thought of 
15 happening sequentially, from the first definition to the last. This may require each variable 
being defined before it is used. 

Furthermore, there could be several blocks of definitions for a UserVars 
collection, each of which are defining several variables. All of these blocks of definitions can 
be thought of as being evaluated in declaration order in the test plan, and then the variables of 
20 each block are also checked in declaration order. 

Finally, there could be several UserVars collections, each of which define 
variables over several blocks of definitions. All of the variables again can be thought of as 
being initialized in declaration order. Thus, in the above example, the evaluation order would 
be: MyVarsJX, MyVars. Y, YourVars.X, YourVars.Yl, YourVars.Y2, MyVars.Z. 

■ 

25 When a UserVars collection uses a variable from another collection, it preferably 

uses just the raw value of the variable. No dependency information is maintained between 
collections. Thus, dependency based re-evaluation can be limited to a single collection. 

Each user variables collection refers to an instance of a C++ UserVars class. The 
default object of the C++ UserVars class is named " UserVars". Variables in an UserVars 
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declaration that is unnamed are from the default user variables collection, and are added to this 
default object. Variables in a named user variables collection are added to an object of the C++ 
UserVars class having that name. In the above example, the "MyVars" C++ object will end up 
having the variables X, Y and Z. 

C++ for User Variables 

User variables are implemented as a collection of w-tuples having the name string, 
a const/var boolean, the type as an enumerated value and the expression as an expression tree. 
The expression of a name can be set by a call: 

enum ElemenaryType {UnsignedlntegerT, IntegerT, 

DoubleT, VoltageT, ...}; 

Status setExpression(const String& name, 

const bool isConst, 
const elementaryType, 
const Expression& expression); 

The type Expression is a type that is a parsed form of the text corresponding to 
the right hand side of an assignment. There will be a globally available instance of UserVars. 
For example, the set of user variables in limits.usrv (cf. page) is implemented by the set of calls 
shown below: 

_UserVars.setExpression("MaxInteger", true, IntegerT, 

Expression(2147483647)); 

JJserVars.setExpression('MinInteger", true, IntegerT, 

Expression(-2147483648)); 

_UserVars.setExpression("Epsilon", true, DoubleT, 

Expression^ .2204460492503 1 3 1 e-0 1 6)); 

JUserVars.setExpression("MaxDouble", true, DoubleT, 

Expression(1.7976931348623158e+308)); 
_UserVars.setExpression( u MinDouble", true, DoubleT, 

Expression("- MaxDouble")); 
JJserVars.setExpression("ZeroPlus", true, DoubleT, 

Expression(2.2250738585072014e-308)); 
_UserVars.setExpression( w ZeroMinus", true, DoubleT, 

Expression("- ZeroPlus")); 
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Below are the C++ statements that would be executed for the variables declared 
in myvars.usrv: 

myVars.setExpressionC'VInLow", true, VoltageT, 

Expression(Q.O)); 
myVars.setExpression("VMfigh", true, VoltageT, 

Expression(5.0)); 
myVars.setExpression('T)eltaT", true, TimeT, 

Expression(2.0E-9)); 
myVars.setExpression(XlkTick", true, TimeT, 

Expression(1.0E-9)); 
my Vars . setExpression("Rl 0", true, ResistanceT, 

Expression(10.0E+3)); 
myVars.setExpression("ILow' , , false, CuirentT, 

Expression(1.0E-3)); 
myVars.setExpression("IHigh", false, CurrentT, 

Expression(2.0E-3)); 
myVars.setExpression("PLow", false, PowerT, 

Expression("ILow * VInLow")); 
myVars.set£xpression("PHigh", false, PowerT, 

Expression("lHigh * VInHigh")); 
myVars.setExpression("ABusVil[0]", false, VoltageT, 

Expression(l.O)); 
myVars.setExpression("ABusVil[l]", false, VoltageT, 

Expression(L2)); 
myVars.setExpressionC'ABusViip]", false, VoltageT, 

Expression(1.5)); 
myVars.setExpression("ABusVil[3]", false, VoltageT, 

Expression(l.S)); 
myVars.setExpression("ABusVil[4]", false, VoltageT, 

Expression(l.S)); 
myVars.setExpression("ABusVil[5]", false, VoltageT, 

Expression(l.S)); 
myVars.setExpression("ABusVil[6]", false, VoltageT, 

Expression(l.S)); 
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myVars.setExpression( l, ABusVil[7]", false, VoltageT, 

Expression(1.5)); 

In the code above, the Expression class preferably has constructors that represent 
the parsed form of the expression. Expression has several constructors, including one that takes 
a string literal and parses it, and another that takes a string literal to use just as a string literal. 
These are distinguished by additional parameters which are not specified above for the sake of 
readability. 

User variables in the default user variables collection will be managed by the 
JJserVars object of class UserVars. User variables in a named user variables collection Xxx 
will be managed by a UserVars object named Xxx. 

Runtime API for UserVars 

The C++ UserVars class that contains these names and expressions exports an 

* 

application programming interface (API) to evaluate and modify these values at runtime. 
Modification of the expressions associated with UserVars also addresses the issue of when the 
UserVars will be reevaluated, and what the impact of the evaluation will be. 

Consider first the issue of when the re-evaluation of UserVars as a result of a 
change should be triggered. If it is triggered immediately upon making a change to the 
expression, then the user would not be able to make a series of related changes prior to 
triggering the re-evaluation. Consequently, re-evalutation is triggered by an explicit call by the 
user. 

The impact of revaluation can be considered next. There are three kinds of re- 
evaluation that are available in accordance with the preferred embodiment: 

UserVars Collection Re-evaluation is re-evaluation limited to a single UserVars 
collection. The semantics of this operation is to re-evaluate all the variables of this collection 
once again. 

UserVars Targeted Re-evaluation is re-evaluation limited to a change to the 
expression bound to a single name. This would enable the user to change the expression of a 
single name, and cause the re-evaluation of the collection to take place, taking into 
consideration only this particular change. 
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User Vars Global Re-evaluation is re-evaluation of all UserVars collections. 
This basically triggers a re-evaluation of all the UserVars collections in declaration order and is 
quite costly. 

All of the above re-evaluations will re-evaluate dependent objects such as Levels, 
5 Timings, etc. after re-evaluating the UserVars. Dependent objects will have a dirty bit that 
represents that it needs re-evaluation. Any time a UserVars collection is programmatically 
changed, it will also set the dirty bit on all dependent objects. This will trigger re-evaluation of 
the dependent objects. 

In summary, named UserVars collections help contain the re-evaluation impact 
10 problem. Re-evaluation is normally limited to a single collection. A simple way of using 

UserVars would be to only use the default UserVars collection. That way, the ripple effect of 
making a change can happen to all UserVars. This ripple effect can be limited by having 
several named UserVars collections. 

Multiple collections can refer to variables from one another, but the values bound 
15 to the variables are bound at time of use. No dependency is maintained between UserVars 
collections. 

For each elementary type Xxx (Unsignedlnteger, Current, Voltage, etc.), a 
method to get the value: 

Status getXxxValue(const String& name, Xxx& value) const; 

20 Note that there is no method to directly set a value, it is done through the call to set the 
expression, followed by a call to reevaluateCollectionO. 

Methods to get and set the expression. The setExpressionO call can also be used 
to define a new variable which was not hitherto defined. 

enum elementaryType 
25 { 

UnsignedlntegerT, IntegerT, DoubleT, VoltageT, ... 

}; 

Status getExpression(const String& name, 

Expression& expression) const; 
30 Status setExpression(const String& name, 
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const bool isConst, 

const elementaryType, 

const Expression& expression); 

The setExpressionO call can fail if the expression results in a circular 
dependency. For instance if the following two calls were made, the second call would fail with 
a circular dependency failure 

setExpression("X", true, IntegerT, Expression("Y+l")); 
setExpression("Y", true, IntegerT, Expression("X+l")); 

This is because the values bound to names are equations and are not assignments. When the 
value of a variable is changed, a method is provided to re-evaluate all the directly and indirectly 
dependent names. Equations such as the above pair result in a circular dependency which is not 
permitted. 

Note that this API does not typically support unsolicited re-evaluation. A call to 
setExpressionO may not automatically cause the variable, and all other variables that depend on 
it, to be re-evaluated. The values bound to all variables will stay unchanged until a call to 
reevaluateCollectionO (below) occurs. 

A method to determine if a particular name is a constant: 

Status getIsConst(const String& name, bool& isConst); 

A method to get the type: 

enum ElementaryType 
{ 

UnsignedlntegerT, IntegerT, DoubleT, VoltageT, ... 

}; 

Status getType(const String& name, 

ElementaryType& elementaryType) const; 

The UserVars Collection Re-evaluation method. 
Status reevaluateCollectionO; 

The class will maintain equations related to all the variables, and their 
dependencies. When this method is called, all of the variables will get re-evaluated. 
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The UserVars Targeted Re-evaluation method. 

Status reevaluateTargeted(const String& var); 

The class will maintain equations related to all the variables, and their 
dependencies. When this method is called, the named variable, and all of its dependents will get 
5 re-evaluated. 

The UserVars Global Re-evaluation method. 

static Status reevaluateAHCollectionsO; 

The class will maintain equations related to all the variables, and their 
dependencies. When this method is called, reevaluateCollectionO is called on all UserVars 
10 collections in an unspecified order. - 

A method to determine if a particular name is defined: 

Status getIsDefined(const String& name, bool& isDefined) const; 

A method to determine all the user variables currently defined: 
Status getNames(StringList& names) const; 

15 A method to delete a presently defined variable: 

Status deleteName(const String& name); 

This operation will fail if the name is used in expressions involving other 

variables. 

A method to get the list of variables and constants that depend on a given variable or constant: 
20 Status getDependents(const String& name, StringList& dependents); 

Specification Sets 

The Specification Set is used to supply a collection of variables which can take 
on values based on a Selector. For example, consider the following Specification Set that uses 
selectors Minnie, Mickey, Goofy and Daisy: 
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# 

# File Aaa.spec 
# 



Version 1.0; 



Import Limits.usrv; 



SpecificationSet Aaa(Minnie, Mickey, Goofy, Daisy) 
10 { 

Double xxx = 1.0, 2.0, 3.0, 4.0; 
Integer yyy = 10, 20, 30, 40; 
Integer zzz = Maxlhteger - xxx, 

MaxJhteger - xxx - 1, 

1 5 Maxlnteger - xxx - 2, 

Maxlnteger - xxx; 



# The following declaration associates a single 

# value, which will be chosen regardless of the 
20 # selector. It is equivalent to: 

# Integer www = yyy + zzz, yyy + zzz, yyy + *7.7 ; yyy + zzz 
Integer www = yyy + zzz; 

The above Specification Set with the selector Goofy will make the following 

25 associations: 

xxx = 3.0; 

yyy = 30; 

zzz = Maxlnteger - xxx - 2; 
www = yyy + zzz; 

30 The operation of setting the selector on a specification set will be discussed later, 

when Tests are described. 

Syntactically, a specification set a is list of selectors (Minnie, Mickey, Goofy and 
Daisy in the example above), along with a list of variable definitions (xxx, yyy, zzz and www in 
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the example above). The definition of a variable involves a list of expressions that is either as 
long as the list of selectors, or comprises a single expression. 

Conceptually a specification set can be thought of as a matrix of expressions, 
whose columns are the Selectors, whose rows' are the variables and whose entries are 
5 expressions. A particular selector (column) binds each variable (row) to a specific expression 
(entry). If the list has a single expression, it represents a row with the expression replicated as 
many times as there are selectors. 

Specification sets can appear in two separate contexts. They could be separately 
declared in a .spec file, in which case they appear as shown above. These are named 
10 specification sets. Otherwise, local specification sets can be declared within a Test Condition 
Group. In such a declaration, the specification set will not be provided with a name. It will be a 
local specification set, of significance only to the enclosing test condition group. 

Named specification sets can be modeled after the named user variables 
collection. The above specification set can be modeled as a UserVars collection named Aaa, 
1 5 which will have expressions for xxx[Minnie], xxx[Mickey], xxx[Goofy], xxx[Daisy], 

yyyjMinnie], and so on. When a particular selector (say Mickey) is chosen in the context of a 
test, the values of xxx, yyy and zzz are obtained from the variable name and the specification set 
name. 

* 

A test condition group can have at most one specification set, which is either a 
20 local specification set, or a reference to a named specification set. Local specification sets 
appear only in the context of a test condition group, and have no explicitly specified name. 
Such a specification set has an implicit name that is defined by the name of the enclosing test 
condition group. To resolve a name in a test condition group at a point where several 
specification sets and several UserVars collections are visible, the following rules are applied: 

25 1. If the name is qualified, it must be resolved in a named user variables collection. 

2. If the name is not qualified, the name is resolved in either a local specification 
set, if it is declared in the test condition group, or in the named specification set, 
if one is referenced in the test condition group. 

3. If the name is not resolved by the earlier rules, it is resolved in the default user 
30 variables collection. 
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To illustrate these rules, consider the following example using Test Conditions 
Groups (to be described later) 

♦ 

Version 1.2.3; 

Import limits.usrv; # Picks up the limits UserVars file above. 
Import aaa.spec; # Picks up the Specification Set AAA above. 

TestConditionGroup TCG1 

{ 

SpecificationSet(Min, Max, Typ) 

{ 

vcc = 4.9, 5.1,5.0; 

} 

# Rule 1 : Resolution in a named user variables collection. 

# A reference to MyVars.VInLow refers to VInLow from MyVars. 

# Rule 2: Resolution in a local specification set. 

# A reference to "vcc" here will resolve in the context 

# of the local specification set above. 

# Rule 3: Resolution in default user variables collection. 

# A reference to "Maxlnteger" here will resolve to limits.usrv. 

# Error: Resolution of xxx 

# A reference to xxx does not resolve because it is neither in 

# the local specification set, nor in limits.usrv. 

# Error: Resolution of Aaa.xxx 

# Looks for a named UserVars collection named Aaa. The named 

# specification set does not qualify. 



TestConditionGroup TCG2 
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{ 



SpecificationSet Aaa; # References the imported specification set 

# Rule 1 : Resolution in a named user variables collection, 

# A reference to MyVars.VTnLow refers to VInLow from MyVars. 



# Rule 2: Resolution in a named specification set. 

# A reference to "xxx" here will resolve in the context 

# of the local specification set Aaa above. 



# Rule 3: Resolution in default user variables collection. 

# A reference to "Maxlhteger" here will resolve to limits.usrv. 



# Error: Resolution of vcc 

15 # A reference to vcc does not resolve because it is neither in 

# the named specification set Aaa, nor in limits.usrv. 

# Error: Resolution of Aaa.xxx 

# Looks for a named UserVars collection named Aaa. The named 
20 # specification set does not qualify. 

Resolution of a name in a specification set (rule above) requires that a selector of 
the set be enabled at the time the name resolution is required. This will be enforced by the fact 
that the test condition group will be referenced in a Test by specifying a selector. 

25 C++ for Specification Sets 

Using the above rules, Specification sets can be implemented by the C++ 
SpecificationSet class. The SpecificationSet class has essentially the same API as the UserVars 
class, except for an extra String parameter for the selector. Consequently, this API is not 
described in detail. 



30 



All named specification sets are preferably associated with a C++ object of that 
name. A local specification set in the context of a test condition group will have a name that is 
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unique to that test condition group. It is illegal to refer to a variable of a local specification set 
outside the context of the test condition group that it is defined in. 

Levels 



The Levels are used to specify parameters of pins and pin groups. It is a 
5 collection of declarations of the form: 

<pin-or-pin-group-name> 

{ 

<pin-param-l> = xxx; 
<pin-param-2> = yyy; 

10 

} 

Such a declaration specifies the setting of the various parameters of the named 
pin or pin-group. For example, such a statement could be used to set the VIL values for all pins 
in the InputPins group, as shown in the example below: 

15 

# 

# File pentiumlevels.lvl 

# m 

■ 

20 Version 1.0; 

Import pentium3resources.rsc; 
Import pentium3pins.pin; 



25 Levels Pentium3Levels 

{ 

# 

# Specifies pin-parameters for various pins and 

# pin groups using globals and values from 
30 # the specification set. 

# 

# The order of specification is significant. 
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# Pin parameters will be set in order from 

# first to last in this Levels section, and 

# from first to last for each pin or pin-group 

# subsection. 
# 

# From the imported pin description file pentium3pins.pin, 

# the InPins group is in the "dpin" resource. From the 

# imported resource definition file pentium3resources.rsc, 

# the "dps" resource has parameters named VEL and VIH. 
# 

InPins { VIL - vjl; VIH = vjh + 1 .0; } 

* 

r 

# The following statement requires a delay of 10 uS after 

# the call to set the InPins levels. Actual delay will be 

# a small system defined range around 10.0E-6: 

# 10.0E-6 - delta <= actual <= 10.0E-6 + delta 
Delay 10.0E-6; 

# 

# For the OutPins, the levels for the parameters 

# VOL and VOH are specified. 
# 

OutPins { VOL = v_ol / 2.0; VOH = voh; } 

# The clock pin will have special values. 
Clock { VOL = 0.0; VOH = vjh / 2.0; } 

# A Delay of 10 uS after the call to set Clock levels. 

# This is a minimum delay, that is guaranteed to be for 

# at least 10.0 uS, though it may be a little more: 

# 10.0E-6 <= actual 10.0E-6 + delta 
MinDelay 10.0 uS; 
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# 

# The PowerPins group is in the "dps" resource. Pins of this 

# pin group have special parameters: 

# PREJWATT specifies the time to wait after voltage 

# reached its final value to start pattern 

# generation. Actual wait time will be a small 

# system defined range around PREJWATT (see) 

# POSTJWAIT specifies the time to wait after pattern 

# generation ends to shut down the power. Actual 

# wait time will be a small system defined range 

# around PREJWATT (see). 
# 

PowerPins 

{ 

PRE_WAIT = 10.0 ras; 
POST WATT = 10.0 ms; 

# VCC reaches its final value of 2.0 V from its 

# present value in a ramp with a Voltage Slew Rate 

# of ±.01 Volts per Second. 
VCC = Slew(0.0 1,2.0 V); 

} 

} 



Levels Pentium4Levels 
{ 

$ ... 

} 

As seen above, each Levels block is preferably made up of a number of levels 
items, each of which specifies parameters for a pin or pin group. Each levels item can specify a 
number of resource parameters. The runtime semantics for the setting of these levels values is 
as follows: 
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» 

The levels items of the Levels block are processed in declaration order. Any pin 
that occurs in more than one levels item will get processed multiple numbers of times. Multiple 
specification of values for a single parameter should be maintained and applied in specification 
order. 

5 The resource parameters in a levels item are processed in the order they are 

specified. 

The Delay statements cause the process of setting levels to pause for 
approximately the indicated duration, prior to setting the next group of levels. The actual wait 
time may be in a small system defined range around the specified delay. So if the delay was t 
10 seconds, the actual delay would satisfy: 

t - At <= actual-wait <= t + At 

The Delay statements divide up the Levels specification into a number of 
subsequences, each of which will require separate Test Condition Memory settings for 
processing. 

15 The MinDelay statements cause the process of setting levels to pause for at least 

the specified duration prior to setting the next group of levels. The actual wait time may be in a 
small system defined range with a minimum value of the specified minimum delay. So if the 
minimum delay was t seconds, the actual delay would satisfy: 

t <= actual-wait <= t + At 

20 The MinDelay statements divide up the Levels specification into a number of 

subsequences, each of which will require separate Test Condition Memory settings for 
processing. 

Each pin or pin-group name is specified in exactly one resource in a pin 
description file (suffix .pin), and therefore has a certain set of viable resource parameters 
25 specified in the resource file (suffix .rsc). All the parameters named must be from among this 
set of viable resource parameters, and must be of the same elementary type as the expression 
used to set their value. Information about the names and types of resource parameters comes 
from the resource file. 



30 



The resource file Resources.rsc is implicitly imported, providing tester with the 
names and types for parameters of standard resources such as dpin, and dps. 
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Resource parameters are assigned expressions that can use UserVars, and values 

■ 

from named specification sets or a currently visible local specification set. 

Dps pin resources have special parameters PRE_WAIT and POST_WATT. The 
PRE_WAIT parameter specifies the time that needs to elapse from the time the power pin has 
5 reached its destination voltage to the time pattern generation can start. The POST_WAIT 

parameter specifies the time that needs to elapse from the time pattern generation has stopped to 
the time the power pin shuts off. 

Dps pins also specify how the voltage parameter reaches its final value. They 
could specify it simply by an equation, as all other pin parameters. Li that case the value will be 
10 reached as the hardware allows it. They could also specify it using a Slew statement. A Slew 
statement specifies that the power supply voltage reaches its final value from the initial value in 
a ramp with a specified absolute Voltage Slew Rate. 

C++ for Levels 

With above rules, a C++ Levels object can be written that supports the following 

15 operations: 

There is an operation 

Status setParameter(const String& pinOrPinGroupName, 

const String& parameterName, 
ElementaryType elementaryType, 
20 const Expression& Expression); 

This operation binds an expression to a parameter of a pin or a pin group. For 
instance, the dpin.InPins VIH value is set by: 

setParameterC'InPins", "VIH", VoltageT, 

Expression("v_ih + 1.0"); 

25 This operation will be called several times for all the declarations in the Levels 

object. 

There is an operation 

Status assignLevels(const String& selector); 
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which will go through and issue all .the pre-determined module level interfaces 
to assign all the levels of parameters in specification order, as described earlier. 
The selector parameter is used to resolve names in the expressions according to 
the rules specified earlier. 

Test Condition Groups 

The Test Condition Group Sub-language packages together the description of 
specificatiofis, timings and levels. Timing objects are often specified using parameters. 
Parameters can be used in timings to specify leading and trailing edges of various pulses. 
Likewise, Levels can be parameterized by specifying maximum, minimum and typical values of 
various voltage levels. A Test Condition Group (TCG) object lumps together the specifications 
and the instantiation of Timings and Levels based on these specifications. 

A TestConditionGroup declaration contains an optional SpecificationSet. The 
. SpecificationSet declaration may be an inlined (and unnamed) local SpecificationSet, or it may 
be a reference to a named SpecificationSet declared elsewhere. The optional SpecificationSet 
declaration in a TCG declaration is followed by at least one Levels or Timings declaration. It 
can have both Levels and a Timings, in any order. However, it is disallowed from having more 
than one Levels and Timings declaration. These restrictions are syntactically enforced. 

A specification set declaration in a TCG is identical to the specification set 
declared separately, except that it does not have a name. Its name is implicitly the name of the 
enclosing TCG. The Timings declaration comprises a single declaration of a Timings object 
from a specified timings file. Here is an example of a file with a test condition group: 

# 

# File myTestConditionGroups.tcg 

# 

Version 0.1; 

Import pentiumlevels.lvl; 
Import edges.spec; 
Import timing 1 .tim; 
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Import timing2.tim; 



TestConditionGroap TCG1 
{ 

5 # This Local SpecificationSet uses user-defined selectors 

# "min", tc max" and "typ". Any number of selectors with any 

# user defined names is allowed. 
# 

# The specification set specifies a table giving values for 
10 # variables that can be used in expressions to initialize 

# timings and levels. The specification set below defines 

# values for variables as per the following table: 

# min max typ 

# v_cc 2.9 3.1 3.0 

15 # vjh vlnHigh + 0.0 vlnHigh + 0.2 vlnHigh + 0.1 

# vjl vWLow + 0.0 vInLow + 0.2 vInLow + 0.1 
$ ... 

* 

# A reference such as 'VlnHigh" must be previously defined 

# in a block of UserVars. 
20 # 

# Thus, if the "max" selector was selected in a functional 

# test, then the "max" column of values would be bound to 

# the variables, setting v_cc to 3.1, vjh to vInHigh+2.0 

# and so on. 
25 # 

# Note that this is a local specification set, and has no 

# name. 

SpecificationSet(min, max, typ) 

{ 

30 # Minimum, Maximum and Typical specifications for 

# voltages. 

Voltage v_cc = 2.9, 3.1, 3.0; 
Voltage vjh - vlnHigh + 0.0, 

vlnHigh + 0.2, 



* 
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vlnHigh + O.l; 
Voltage v_il = vlnLow + 0.0, 

vInLow + 0.2, 
vlhLow + O.l; 



# Minimum, Maximum and Typical specifications for 

# leading and trailing timing edges. The base 

# value of 1.0E-6 uS corresponds to 1 picosecond, 

# and is given as an example of using scientific 
10 # notation for numbers along with units. 

Timet_le=1.0E-6 uS, 

1.0E-6uS + 4.0* DeltaT, 
1.0E-6uS + 2.0 *DeltaT; 

Time t_te = 30ns, 
15 30ns + 4.0 * DeltaT, 

30ns + 2.0 * DeltaT; 

} 



# Refers to the Pentium3Levels imported earlier. It 
20 # is one of possibly many levels objects that have been 

# imported from the above file. 
Levels Pentium3Levels; 

# Refers to file timing l.tim containing the single 

25 # timing Timingl . The filename should be quoted if 

# it has whitespace characters in it. 
Timings Timingl; 

} 

30 # Another test condition group 

TestConditionGroup TCG2 

{ 

# ClockAndDataEdgesSpecs is a specification set which 

# is available in the edges.specs file. Assume it has 
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# the following declaration: 

# SpecificationSet aockAndDataEdgesSpecs(min, max, typ) 

# { 

# Time clockje = 10.00 uS, 10.02 uS, 10.01 uS; 
5 # Time clockje = 20.00 uS, 20.02 uS, 20.0 1 uS; 

# Time dataje = 10.0 uS, 10.2 uS, 10.1 uS; 

# Time dataje = 30.0 uS, 30.2 uS, 30.1 uS; 

# } 

# A SpecificationSet reference to this named set is below: 
1 0 SpecificationSet ClockAndDataEdgesSpecs; 

# An inlined levels declaration. Since the associated 

# specification set (above) does not have variables such 

# as VInLow, VThHigh, VOutLow and VOutHigh, they must 
15 # resolve in the default UserVars collection. 

Levels 

{ 

InPins { VIL = VInLow; VIH - VInHigh + 1.0; } 
OutPins { VOL = VOutLow / 2.0; VOH = VOutHigh; } 

20 } 



# This Timing is from the file "timing2.tim". The timings 

# will need the leading and trailing edge timings for clock 

# and data as specified in the above specification set. 
25 Timings Timing2; 

) 

In the above example, the test condition group TCG1 describes a specification 
set with three selectors named "min", "typ" and "max". There can be any number of distinct 
selectors. Within the body of the specification set, variables vjl, vjh, t_le and tje are 
30 initialized with triples of values, corresponding to the selectors. So in the above example, an 

instance of TCG1 with the selector "min" will bind the variable v_il with the first numeric value, 
(vlnputLow+O.O). It bears repetition that the selectors for a specification set are user defined, 
and any number of them is allowed. The only requirement is that: 

The selectors of a specification set be unique identifiers. 
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Each value specified in the specification set is associated with an array of values 
that exactly the same number of elements as the set of selectors. Picking the z ,th selector will 
cause each value to be bound to the i* value of its associated vector of values. 

Subsequent to the specification set in the TCG, there could be a Levels 
5 declaration or a Timings declaration or both. The Levels declaration is used to set levels for 
various pin parameters. The variables identified in the specification set will be used to set these 
levels, permitting a dynamic binding of different actual values for pin parameters based on the 
selector used to initialize the TCG. 

To exemplify this, consider a Test that enables the selector "min". Referring to 
10 the specification set Pentium3Levels given on page, the pin parameter "VTH" for pins in the 
InPins group will be initialized to the expression (vjh + 1 .0) by the declaration: 

InPins { VIL - vjl; VIH = vjh + 1 .0; } 

This resolves to (VInHigh + 0.0 + 1.0) when the selector "min" is enabled. 
Likewise, the Timings objegt can be initialized based on the selected values of the specification 
1 5 set variables. It is not necessary to have both a Timings and a Levels declaration. Either can be 
present by itself, or both in any order, as illustrated by the following example: 

# . . 

# File LevelsOnlyAndTimingsOnly.tcg 
# 



20 



Version 0.1; 



# A Levels-only Test Condition Group. 
TestConditionGroup LevelsOnlyTCG 
25 { 

SpecificationSet(Min, Max, Typ) 
{ 

Voltage vjl m 0.0, 0.2, 0.1; 
Voltage vjh = 3.9, 4.1,4.0; 

30 } 



# An inlined levels declaration. Since the associated 
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} 

10 



# specification set (above) does not have variables such 

# as VlnLow, VLiHigh, VOutLow and VOutHigh, they must 

# resolve in the default UserVars collection. 
Levels 

{ 

InPins { V1L = v_il; VIH = v_ih + 1.0; } 
OutPins { VOL = v_il / 2.0; VOH = v_ih; } 

} 



# A Timings-only Test Condition Group 
TestConditionGroup TimingsOnlyTCG 
{ 

15 SpecificationSet(Min, Max, Typ) 

{ 

Time t_le = 0.9E-3, 1.1E-3, 1.0E-3; 

} 

20 Timings Timing2; 

} 

Note, however, there should not be more than one Timings and more than one 
Levels in a TCG. Thus, in summary, there should be at least one of Timings or Levels, and at 
most one of each. 

25 Test Conditions 



A TestCondition object ties a TCG to a specific Selector. Once a TCG has been 
declared as shown above, it is possible to declare TestCondition objects as shown below: 

TestCondition TCMin 
{ 

30 TestConditionGroup = TCG1; 

Selector = min; 

} 
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TestCondition TCTyp 
{ 

TestConditionGroup = TCG1 ; 
Selector = typ; 

} 

TestCondition TCMax 
{ 

TestConditionGroup = TCG1 ; 
Selector = max; 

} 

These Test Conditions would be instantiated in a Test Plan as follows: 
# 

# Declare a FunctionalTest "MyFunctionalTest" that refers to three 

# Test Condition Group instances. 
# 

Test FunctionalTest MyFunctionalTest 

{ 

# Specify the Pattern List 
PList = patl Alist; 

# Any number of TestConditions can be specified: 
TestCondition = TCMin; 

TestCondition = TCMax; 
TestCondition = TCTyp; 

} 

Name Resolution in TCGs (test condition groups) 

Resolution of names in a test condition group was discussed earlier. However, 
these rules bear repetition, and are given below again: 

1 . If the name is qualified (cf page), it must be resolved in a named user variables 
collection. 
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2. If the name is not qualified, the name is resolved in either a local specification 
set, if it is declared in the test condition group, or in the named specification set, 
if one is referenced in the test condition group. 

3. If the name is not resolved by the earlier rules, it is resolved in the default user 
5 variables collection. 

TCG Runtime 

Test condition groups have the following runtime semantics: 

A Test (such as a FunctionalTest) will reference a TCG with a particular selector 
from its SpecificationSet, using an instantiated TestCondition. This selector will bind each 
1 0 variable in the SpecificationSet to its value associated with the chosen selector. This binding of 
variables to their values will then be used to determine Levels and Timings. 

Parameter Levels in a TestConditionGroup are preferably set sequentially, in the 
order of presentation in the Levels block. So in the Pentium3Levels block, the order in which 
parameter levels would be set is as follows (notation: <resource-name>.<resource-parameter>): 

15 IhputPins.VEL, 

fciputPins.VIH, 

OutputPins.VIL, 

OutputPins.VIH, 

Clock. VOL, 
20 Clock.VOH. 

This sequencing order enables the test writer to control the explicit power 
sequencing of power supplies. Furthermore, if a levels item occurs twice, naming the same pin- 
parameters for a pin, then that pin-parameter gets set twice. This can happen programmatically 
also. 

25 If a parameter is set by a Slew statement such as 

VCC = SIew(0.0 1,2.0 V); 



WO 2004/072670 



PCT/JP2004/001649 



73 

it means that VCC will reach its final value of 2.0 volts from its present value in a ramp with a 
Voltage Slew Rate of ± 0.01 volts per second. 

Specification set variables can also be passed into a Timings object in the TCG. 
The Timings object will then be initialized based on the selected variables. Such a mechanism 
5 could be used to customize a Timings object, as, for instance, by specifying leading and trailing 
edges of waveforms. 

OH-ibrTCGs 

With the above rules, the Test Condition Group can be declared in a C++ 
TestConditionGroup class, and initializing it as follows: 

10 A call is made to the TestConditionGroup member function 

Status setSpecificationSet(SpecificationSet *pSpecificationSet); 

which will set the specification set for the TestConditionGroup. This may either be a local 
specification set, or a named specification set, or null (if there is none). 

i 

A call is made to the TestConditionGroup member function 
15 Status setLevels(Levels *pLevels); 

which will set the Levels object for the TestConditionGroup. This may either be a locally 
declared levels object, or an externally declared levels object, or null (if there is none). 

A call is made to the TestConditionGroup member function 

Status setTimings(Timings *pTimings); 

20 which will set the Timings object for the TestConditionGroup. This will be either an externally 
declared Timings object, or null (if there is none). 
Bin Definitions 

The Bin Definitions class defines bins, a collection of counters that summarize 
the results of testing many DUTs. During the course of testing a DUT, the DUT can be set to 
25 any bin, e.g., to indicate the result of a particular test. As testing proceeds, the DUT may be set 
to another bin. The bin that the DUT is finally set to is the last such setting at the end of the test. 
The counter for this final bin is incremented at the end of the test of this DUT. A separate file 
with bin definitions should have the suffix .bdefs. 
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Bin definitions are preferably hierarchical. For example, at an outermost level, 
there may be the PassFailBins with two bins named Pass and Fail. Then there could be several 
HardBins, some of which map to the Pass bin, and others which map to the Fail bin. The 
HardBins are said to be a refinement of the PassFailBins. Finally, there could be a large number 
5 of SoftBins, a refinement of HardBins, many of which map to the same Hard bin. Below is an 
example illustrating the hierarchy of bins: 

# 

■ 

# File pentiumbins.bdefs 

# 

10 

Version 1.2.3; 

BinDefs 

{ 

# The HardBins are an outermost level of 

#bins. They are not a refinement of any other 

# bins. 

BinGroup HardBins 
{ 

"3GHzPass": "DUTs passing 3GHz"; 
"2.8GHzPass": "DUTs passing 2.8GHz"; 
"3GHzFail": "DUTs failing 3GHz"; 
"2.8GHzFail": "DUTs failing 2.8GHz"; 
LeakageFail: "DUTs failing leakage"; 

} 

# The SOflBins are a next level of refinement. 

# SoftBins are a refinement of HardBins. 
BinGroup SoftBins : HardBins 

30 { . 

+ 

"3GHzAllPass": 

"Good DUTs at 3GHz", "3GHzPass"; 
"3GHzCacheFail": 

"Cache Fails at 3GHz", "3GHzFail"; 



15 



20 



25 
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"3GHzSBFTFail": 

"SBFT Fails at 3GHz", "3GHzFail"; 
"3GHzLeakage": 

"Leakages at 3GHz", LeakageFail; 
5 "2.8GHzAllPass": 

"Good DUTs at 2.8GHz", "2.8GHzPass"; 
"2.8GHzCacheFail": 

"Cache Fails at 2.8GHz","2.8GHzFail"; 
"2.8GHzSBFTFail": 

10 "SBFT Fails at 2.8GHz", "2.8GHzFail"; 

"2.8GHzLeakage": 

"Leakages at 2.8GHz", LeakageFail; 

} 

} 

15 In the above example, the most base bins are the BinGroup HardBins. A 

BinGroup X is said to be a group of base bins if some other BinGroup is a refinement of X. 
Thus, the BinGroup HardBins is a group of base bins since the BinGroup SoftBins is a 
refinement of HardBins. The bins of SoftBins are referred to as leaf bins. A BinGroup Y is 
said to be a group of leaf bins if no other BinGroup is a refinement of Y. 

20 The degenerate case of a BinDefs block with a single BinGroup Z in it will have 

Z to be a group of most base bins, as well as a group of leaf bins. BinGroup names are global in 
scope. There can be any number of BinDefs blocks, but the declared BinGroups must be 
distinct. A BinGroup from one BinDefs block is allowed to be a refinement of a BinGroup from 
another BinDefs block. So in the above example, SoftBins could be in a separate BinDefs block 

25 from HardBins. However, it is strongly recommended to have a single BinDefs block with all 
the BinGroups defined for the sake of readability. 

The above hierarchy can now be extended to count how many DUTs passed and 
failed, by adding another BinGroup. 

# 

30 # File pentiumbins .bdefs 

# 

Version 1.2.3; 
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BinDefs 

{ 

# The PassFailBins are an outermost level of 

# bins. They are not a refinement of any other 
#bins. 

BinGroup PassFailBins 
{ 

Pass: "Count of passing DUTS/'; 
Fail: "Count of failing DUTS."; 

} 

# The HardBins are a next level of refinement. 

# HardBins are a refinement of the PassFailBins, 

# as indicated by "HardBins : PassFailBins". 
BinGroup HardBins : PassFailBins 

{ 

"3GHzPass": "DUTs passing 3GHz", Pass; 
"2. 8GHzPass": "DUTs passing 2.8GHz", Pass; 
"3GHzFail": "DUTs failing 3 GHz", Fail; 
"2.8GHzFail": "DUTs failing 2.8GHz", Fail; 
LeakageFail: "DUTs failing leakage",Fail; 

} 

# The SofiBins are a next level of refinement. 

# SofiBins are a refinement of HardBins. 
BinGroup SofiBins : HardBins 

{ 

"3GHzAllPass": 

"Good DUTs at 3GHz", "3GHzPass"; 
"3GHzCacheFail": 

"Cache Fails at 3GHz", "3GHzFail"; 
"3GHzSBFTFail": 

"SBFT Fails at 3GHz", "3GHzFail"; 
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"3GHzLeakage": 

"Leakages at 3GHz", LeakageFail; 
"2.8GHzAllPass": 

"Good DUTs at 2.8GHz", "2.8GHzPass"; 
5 "2.8GHzCacheFail": 

"Cache Fails at 2.8GHz","2.8GHzFail"; 
"2.8GHzSBFTFail": 

"SBFT Fails at 2.8GHz", "2.8GHzFail"; 
"2.8GHzLeakage": 

10 "Leakages at 2.8GHz", LeakageFail; 

} 

} 

This time, the most base bins are the BinGroup PassFailBins. They are typically 
not a refinement of any bins. The BinGroup HardBins are a refinement of the PassFailBins and 
15 are also base bins. SoftBins are a refinement of the HardBins, and are a group of leaf bins. The 

■ 

above example had only three BinGroups in the hierarchy. Below is a more complicated 
hierarchy: 

BinDefs 

{ 

20 # A group of most base bins 

BinGroup A { ... } 

# A group of base bins that is a refinement of A 
BinGroup Ax : A { ... } 

25 

# A group of leaf bins that is a refinement of Ax 
BinGroup Axx : Ax { ... } 

# A group of base bins that is a refinement of A 
30 BinGroup Ay : A { ...} 

# A group of leaf bins that is a refinement of Ay 
BinGroup Ayy : Ay { ... } 
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# A group of most base bins 
BinGroup B { ... } 



# A group of leaf bins that is a refinement of B 
5 BinGroup Bx : B { ... } 

} 

In this example, Ax and Ay are refinements of A, Axx is a refinement of Ax and 
Ayy is a refinement of Ay. This example also provides BinGroups B and Bx where Bx is a 
refinement of B. The BinDefs declaration above with the BinGroups named PassFailBins, 
10 HardBins and SoftBins will be used as a continuing example in this section. 

Each bin in a BinGroup has: 

1 . a name which is either an identifier or a string literal 

2. a description which describes what this bin summarizes 

3 . and if this bin is in a refinement BinGroup, the name of the bin it is a 
1 5 refinement of, also known as the base bin. 

The two bins in PassFailBins are named "Pass" and "Fail". The five bins in 
HardBins are named "3GHzPass", "2.8GHzPass", "3GHzFail", "2.8GHzFail", "LeakageFail". 
Bin names may be a literal string, or an identifier. Bin names must be unique in a BinGroup, 
but may be duplicated across BinGroups. BinGroup names, however, are global in scope, and 
20 must be unique across a test plan. 

Of the five HardBins, the bins "3GHzPass" and "2.8GHzPass" both map to the 
'Tass" bin of the PassFailBins. The rest of the HardBins map to the "Fail" bins of the 
PassFailBins. 

Finally, there are eight SoftBins. The two failures at 3GHz for SBFT (soft bin 
25 functional test) and Cache map to the "3GHzFail" HardBin. Likewise the two failures at 
2.8GHz for SBFT and Cache map to the "2.8GHzFail" HardBin. Both the failures due to 
Leakage map to the same "LeakageFail" HardBin, regardless of the speed at which they 
occurred. For example, the coarsest test (at the outermost level) is whether a DUT passes or 
fails a test. A refinement is, for example, whether the DUT passes or fails a test at a particular 
30 frequency, e.g., 3 GHz, etc. 
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Bins are assigned to DUTs in a Test Plan Flowltem, described below. A TestPlan 
Flowltem has a Result Clause in which the test plan describes the actions and transition to take 
place as the result of getting a particular result back from executing a test. It is at this point that 

p 

a SetBin statement can occur: 

# A Flowltem Result clause. It is described later. 
Result 0 

{ 

# Action to be taken on getting a 0 back from 

* * 

# executing a test. 

# Set the bin to SoftBin."3GHZPass" expressing that the 

# DUT was excellent. 
SetBin SoftBins."3GHzPass ,f ; 

} 

15 Many SetBin statements could execute during the course of running a test on a 

DUT. When the test is finally completed, the runtime will increment counters for the final bin 
that is set for that DUT, and for all its refinements. Consider a DUT which had the following 
SetBin statements executed during the course of its test: 

SetBin Sofffiins.'3GHzSBFTFail"; 
20 SetBin SoflBins."2.8GHzAllPass"; 

This DUT passed the 3GHz Cache and Leakage tests, but failed the SBFT test, 
and so was assigned to the "3GHzSBFTFail" bin. It was then tested at 2.8GHz, and all the tests 
passed. So the final bin assignment is to the "2.8GHzAllPass" bin, which is in the set of 
SoflBins. This final assignment will increment the counters of the following bins: 

25 1. SoflBins. ,< 2.8GHzAllPass w 

2. which is a refinement of HardBins."2.8GhzPass" 

3 . which is a refinement of PassFailBins.'Tass" 

When the test completes, runtime will increment the counter of the final bin 
assignment of the DUT, and for all other bins it is a refinement of. 

30 A SetBin statement is allowed only on a leaf bin. It is illegal to set a base bin. 

The counter incrementing semantics above assures that: 
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1 . If the bin is a leaf bin, it is the number of times a SetBin statement was 
executed for this bin at the end of testing a DUT. 

2. If the bin is a base bin, it is the sum ofthe counters ofthe bins that it is 
a refinement of. 

5 Thus, in the above example, only SoftBins are allowed in a SetBin statement 

The counter for HardBins "LeakageFail" is the sum ofthe counters for 
SoftBins."3GHzLeakageFail" and SoftBins/ 4 2.8GH2LeakageFail". Below are some rules 
regarding bin definitions: 

1. A BinDefinitions declaration is comprised of several BinGroup 
1 0 declarations. 

2. Each BinGroup declaration has a name, an optional BinGroup name 
that it is a refinement of, followed by a block of bin declarations. 

3. Bin declarations comprise a name, followed by a description, optionally 
followed by the name of a base bin that this bin is a refinement of. 

15 4. Bin names can be a string literal, or an Id. The empty string should not 

be a valid bin name. Bin names should be unique among names in the 
BinGroup declaration, but the same name could be used in other 
BinGroup declarations. 

5 . If a BinGroup declaration Xxx is a refinement of another BinGroup 
20 declaration Yyy, then all of the bin declarations in Xxx must declare 

the name of a base bin from Yyy. Thus, each of the bin declarations in 
SoftBins is a refinement of a bin of HardBins. since the SoftBins are 

♦ 

declared to be a refinement of HardBins. 

6. A BinGroup declaration that is not a refinement of another BinGroup 
25 declaration, such as PassFailBins will preferably have Bin declarations 

that do not declare base bins. 

A bin Bbb has a set of bases which is the entire set of bins that Bbb is a 
refinement of. It is formally defined as follows: 

1 . If Aaa is the base bin of Bbb, then Aaa is in the set of bases of Bbb. 
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2. Any base of Aaa is also in the set of bases of Bbb. 
BinGroup names are global in a TestPlan. 
Bin names are local to a BinGroup. 
A SetBin statement is only allowed for a leaf bin. 
C++ for Bin Definitions 

With above rules, an object type BinGroup can be constructed for each of the 
BinGroup declarations in the BinDefs declaration. The class BinGroup will have a subclass 
LeafBinGroup. The operations of these two classes are the same, except that 
BinGroup: :incrementBin is a C++ protected operation, whereas LeafBinGroup: rincrementBin is 
a C++ public operation. 

The following is a default constructor which builds a BinGroup or a 
LeafBinGroup which is not a refinement of any other BinGroup. 

Constructors: 
BinGroup(BinGroup& baseBinGroup); 
LeafBinGroup(BinGroup& baseBinGroup); 
that builds a BinGroup that is a refinement of the given baseBinGroup. 

A method 
Status addBin(const String& binName, 
const String& description, 
const String& baseBinName); 
to define a bin and its description. If it is.a most base bin, the baseBinName parameter must be 
the empty string. 

Methods to increment bin counters: 
Status incrementBin(const String& binName); 
This operation will increment the counter for this bin, and for all bins that are bases of this bin. 
The operation is protected in the class BinGroup, and is public in the class LeafBinGroup. 

Methods to reset bin counters 
Status resetBin(const String& binName); 
This operation will reset the counter for this bin, and for all bins that are the bases of this bin. 
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Methods to get information about a bin: 
Status getBinDescription(const String& binName, 

String& description); 
Status getBaseBin(const String& binName, 
5 BinGroup* pBaseBinGroup, 

String& baseBinName); 
Status getBinValue(const String& binName, 
unsigned int& value); 

Iterators will be provided to get at all the currently defined bin names. 

1 0 TestPlan state will be include number of BinGroup members, one for each 

BinGroup declaration. The C++ for the above BinDefinitions would be as follows: 

// TestPlan constructor 
TestPlan: :TestPlanO 

: mJPassFailBinsO, // Default Constructor 
1 5 m_HardBins(&m_PassFailBins), 

m_SoftBins(&mJHardBins) 

// Bin initializations 

20 mJPassFailBins.addBinCYass", "Count of passing DUTS .",""); 

m_PassFailBins.addBin("Fail", "Count of failing DUTS.",""); 
mJIardBins.addBin("3GHzPass", "Duts passing 3GHz", "Pass"); 



25 State for a TestPlan includes a m jCurrentBinGroup which is initialized to the 

undefined BinGroup (NULL) and the m_currentBin undefined bin name (the empty string). 
Each time a SetBin statement is executed, the m _pCurrentBinGroup is changed to the indicated 
the named BinGroup and the m_currentBin to the named bin in the group by a call: 

// Translation of: SetBin SoftBins."3GHzAllPass"; 
30 pTestPlan->setBin("SoftBins", "3GHzAllPass"); 

When the test plan completes execution, it will call 
mj>QirrentBinGroup->incrementBin(m_currentBin); 
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causing this bin and all its base bins to have their counters incremented. 

The BinGroup counters are reset when the test plan is elaborated, but are not 
reinitialized each time a test is run. The counters can be reset by an explicit call to BinGroup:: 
resetBin. 

C. The Test Plan 

The test plan can be thought of as a main structure of the test program. The Test 
Plan can import files, as well as define similar constructs inline. Thus, it is possible to import a 
file given definitions of some globals, as well as declaring additional globals inline. 

CI. Test Plan Flows and Flowltems 

One of the critical elements of the Test Plan is the Flow. A Flow encapsulates a 
finite state machine. It comprises several Flowltems which run an IFlowable object and then 
transition to another flow item. Running an IFlowable involves running an object that 
implements the IFlowable interface. Typical objects that implement the IFlowable interface are 
Tests and Flows themselves. 

Thus, a Flow has Flowltems which runs Tests and other Flows, and then 
transition to another Flowltem. It also provides for the opportunity to call user customized 
routines on various return results from running an IFlowable. Typically, a Flow thus has the 
following form: 

# 

# FlowTestl implements a finite state machine for the 

# Min, Typ and Max flavors of MyFunctionalTest 1 . On 

# success it tests TestlMin, TestlTyp, TestlMax 

# and then returns to its caller with 0 as a successful 

# status. On failure, it returns 1 as a failing status. 
# 

# Assume that the tests MyFunctionalTestlMin, ... all 

# return a Result of 0 (Pass), 1 and 2 (for a couple 
. # of levels of failure). 

# Result 0 Result 1 Result 2 

# TestlMin TestlTyp return 1 return 1 

# TestlTyp TestlMax return 1 return 1 
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# TestlMax return 0 return 1 return 1 
# 

Flow FlowTestl 

{ . 

5 Flowltem FlowTestl_Min MyFunctionalTestlMin 

{ 

Result 0 

{ 

Property PassFail = "Pass"; 
1 0 IncrementCounters PassCount; 

GoTo FlowTestl JTyp; 

} 



Result 1 

15 { 



20 



Property PassFail = "Fail"; 
IncrementCounters FailCount; 
Return 1; 

} 



# This result block will be executed if 

# MyFunctionalTestlMin returns any of 

# 2, 5, 6, 7, -6, -5 or -4 
Result 2, 5:7, -6:-4 

25 . { 

Property PassFail = "Fail"; 
IncrementCounters FailCount; 
Return 1; 

} 



30 } 



Flowltem FlowTestl_Typ { ... } 
Flowltem FlowTestl_Max { ... } 



} 
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The operation of the Flow FlowTestl is as follows: 

1 . Starts up with executing Flowltem FlowTestlJMin. 

2. FlowTestlJMin runs a functional test, MyFunctionalTestlMin. Details of this 
test are provided when the complete test plan is presented below. 

5 3. Nine results are expected from running this test, 0, 1, 2, 5, 6, 7, -6, -5 or -4. 

The first two Result clauses handle 0 and 1 respectively, and the third handles 
all the rest of the result values. 

4. If result "0" (pass) occurs, then FlowTestl_Min will increment the counter 
PassCounter. It will then transition to a new Flowltem FlowTestl JTyp. 

10 5. If result "1" or result "2" occurs, then FlowTestlJMin will increment the 

counter FailCounter, and return from the flow. 

6. FlowTestl JTyp will operate in the same way, and on success call 
FlowTestlJMax. 

7. FlowTestl_Max will operate in the same way, and on success return from 
1 5 - FlowTestl with a successful result ("0"). 

Thus, FlowTestl will, on a successful run, run a device through the minimum, 
typical and maximum versions of Test 1, and then return. FlowTest2 will operate in a like 
manner. 

A Flow as described above basically describes a Finite State Machine with states 
20 and transitions. The Fiowltems are basically states, which will do the following: 

1 . Execute an IFlowable (it could be a previously defined Flow, or a Test, or a 
user defined Flow that can be implemented in C++ with the above rules). 

2. Execution of the IFlowable return a numeric result. Based on the result, certain 
actions occur (updating some counters), and then one of two things happen: 

25 a. The Flow returns to the caller with a numeric result. 

b. The Flow continues by transitioning to another state (Flowltem). 

Thus, a Flowltem has the following components: 
A Flowltem has a name. 



WO 2004/072670 



PCT/JP2004/001649 



86 

A Flowltem has an IFlowable to be executed. 
A Flowltem has a number or Result clauses. 

Each Result clause of a Flowltem provides actions and ends with a trayisition and is associated 
with one or more result values: 

5 These items are syntactically as follows in a Flowltem. 

Flowltem <name> <IFlowable to be executed> 
{ 

Result <one or more result values> 
{ 

1 0 <actions for these result values> 

<transition for these result values> 



Result <one or more other result values> 
15 { 



} 



} 



20 The IFlowable to be executed could be either a Test, or a User-defined W lowable, 

or a Flow. The actions for a result could be any of the following: 

4 

A Property Action to set string valued entities that are used by GUI tools to attribute 
results. This can be seen in the above FlowTestl example with: 

Property PassFail = "Pass"; 

25 Properties are basically named string or integer valued entities that are associated 

with a Result clause. There can be any number of them, and they are preferably used by tools 
such as GUIs which a user would use to display information associated with this result. They 
have no effect on the actual result of the test, or the flow of the test. 

A Counters Action to increment some number of counters. This can be seen in 
30 the above example with: 



* 
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IncrementCounters PassCount; 
A Routine Call Action to call an arbitrary or user routine. This is discussed later. 

Finally, a Flowltem has a Transition which could either be a GoTo statement to 
transfer control to another Flowltem, or a Return statement to transfer control back to the caller 
(either a calling flow, or the system routine which initiated the test plan). 

Predefined Flows 

The typical use of Flow objects is to define a sequence of Tests. This sequence 
is then executed as a result of an event occurring in a Test Plan Server (TPS), i.e. the Execute 
Test Plan event. A test plan server on each site controller executes the user's test plan. 
However, Flow objects are also executed in response to other events. The name in parentheses 
is the name used in assigning Flows to these events. 

1 . System Load Flow (SysLoadFlow). This Flow is executed on the 
System Controller when a Test Plan is loaded onto one or more Site 
Controllers. It is executed prior to the actual loading of the Test Plan 
on any Site Controller. This flow allows the Test Plan developer to 
define actions that should originate from the System Controller. Such 
actions include broadcast load of Pattern files, Calibration actions, etc. 

2. Site Load Flow (SiteLoadFlow). This Flow is executed on the Site 
Controller after a Test Plan has been loaded onto the Site and initialized. 
This allows any Site-specific initialization to occur. 

3. Lot Start/End Flows (LotStartFlow/LotEndFlow). These Flows execute 
on the Site Controllers when the Test Plan Server is notified of a start 
of a new lot. This is typically used in production environments to 
annotate datalog streams with lot-specific information. 

4. DUT Change Flow (DutChangeFlow). This Flow executes on the Site 
Controller when its DUT information changes. Again, this is typically 
used in production environments to update datalog streams. 
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5 . TestPlan Start/End Flows (TestPlanStartRow/TestPlanEndFlow). 
These Flows execute on the Site Controller when the Test Plan Server 
is instructed to start executing the current Test Flow and when that flow 
finishes its execution. 

6. Test Start/End Flows (TestStartFlow/TestEndFlow). These Flows 
execute on the Site Controller when the Test Flow is starting to run a 
new Test and when that Test finishes its execution. 

7. Test Flow (TestFlow). This Flow is the main Flow object executed 
when the Test Plan Server receives an "Execute Test Plan" message. 

* 

Note that if a user defines a Flow in the user's Test Plan that is not the TestFlow 
or one of the other pre-defined flows, the preferred way to have it executed is to include it in 
the transition states of one of these pre-defined flows. 

A Test Plan Example 

In the example below, Flows are given along with comments that describe the 
finite state machine implemented by the flow. The finite state machine is given as a transition 
matrix. Rows of the matrix correspond to Flowltems, and columns to the result. The entries of 
a row of the matrix indicate the Flowltem that is transitioned to from the Flowltem of the row 
when the returned Result is the value specified in the column. 

A Test Plan with three flows, FlowTestl, FlowTest2 and FlowMain, is shown 
below. FlowTestl will operate as described above. It will run a test named MyFunctionalTestl 
in each of the "min", "typ" and "max" configurations. Likewise, FlowTest2 will run 
MyFunctionalTest2 in each of these configurations. Finally, FlowMain will run FlowTestl and 
FlowTest2. The finite state machine transition matrix is provided in comments at the start of 
each of these flows, 

# 

# File mySimpleTestPlan.tpl 

# ; 



Version 0.1; 
Import xxx.pin; 



#Pins 
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# Constants and variables giving limiting values. 
Import limits.usrv; 

■ 

5 # Import test condition groups 

Import myTestConditionGroups.tcg; 



10 



15 



# Import some bin definitions. 
Import bins.bdefs; 



# Start of the test plan 
#. 

TestPlan Sample; 



# This block defines Pattern Lists file-qualified names and 

# Pattern List variables that are used in Test declarations. 

# Pattern list variables are deferred till customization is 

# examined. 
20 PListDefs 

{ 

# File qualified pattern list names 
pi 1 A.plist:patl Alist, 
pl2A.plist:pat2AList 

25 } 



# The socket for the tests in this test plan (this is not imported, 

# but resolved at activation time): 
SocketDef = mytestsoc; 

# Declare some user variables inline 
UserVars 

{ 

# String name for current test 
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String CurrentTest = "MyTest"; 

} 



TestCondition TClMin 
{ 

TestConditionGroup = TCG1; 
Selector = rnin; 

} 

TestCondition TClTyp 

■ 

{ 

TestConditionGroup = TCG1 ; 
Selector = typ; 

} 

TestCondition TCI Max 

{ 

TestConditionGroup = TCG 1 ; 
Selector = max; 

} 

# Likewise for TC2Min, TC2Typ, TC2Max ... 
# 

# Declare a FunctionalTest. "FunctionalTest" refers to a C++ 

# test class that runs the test, and returns a 0, 1 or 2 as 

# a Result. The Test Condition Group TCG1 is selected with 

# the "min" selector by referring to the TClMin TestCondition. 
# 

Test FunctionalTest MyFunctionalTestlMin 
{ 

PListParam = patl AList; 
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TestConditionParam = TClMin; 

} 



# Another FunctionalTest selecting TCG1 with "typ" 

Test FunctionalTest MyFunctionalTestlTyp 

{ 

PListParam = patlAList; 
TestConditionParam = TCI Typ; 

} 



# Another FunctionalTest selecting TCG1 with "max" 

Test FunctionalTest MyFunctionalTestlMax 

{ 

PListParam = patlAList; 
1 5 TestConditionParam = TC IMax; 

} 



# Now select TCG2 with "min" 

Test FunctionalTest MyFunctionalTest2Min 
20 { 

PListParam = pat2AList; 
TestConditionParam = TC2Min; 

} 

25 # Likewise for TCG2 with "typ" and TCG2 with "max" 

Test FunctionalTest MyFunctionalTest2Typ 
{ 

PListParam = patlAList; 
TestConditionParam = TC2Typ; 

30 } 



Test FunctionalTest MyFunctionalTest2Max 
{ 

PListParam = patlAList; 
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TestConditionParam =* TC2Max; 

} 



# 

5 # At this time the following Test objects have been defined 

# MyFunctionalTestlMin 

# MyFunctionalTestlTyp 

# MyFunctionalTestlMax 

# MyFunctionalTest2Min 
10 # MyFunctionalTest2Typ 

# MyFunctionalTest2Max 
# 

# 

# Counters are variables that are incremented during the 
15 # execution of a test. They are Unsignedlntegers that are 

# initialized to zero. 
# 

Counters {PassCount, FailCount} 

20 # 

# Flows can now be presented. A Flow is an object that 

# essentially represents a finite state machine which 

# can execute "Flowables", and transition to other flowables based 

# on the Result returned from executing a Flowable. A Flow can also 
25 # call another flow. 

# 

# A Flow consists of a number of Flowltems and transitions 

# between them. Flowltems have names which are unique in 

# the enclosing Flow, execute a "Flowable" object, and then 
30 # transition to another Flowltem in the same enclosing Flow. 

# 

# Flowable objects include Tests and other Flows. When 

# a Flowable object executes, it returns a numeric Result 

# which is used by the Flowltem to transition to another 
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# Flowltem. As a result of this, both Tests and Flows 

# terminate by returning a numeric Result value. 
# 

# FlowTestl implements a finite state machine for the 

5 #Min,Typ and Max flavors of MyFunctionalTestl. On 

# success it tests TestlMin, TestlTyp, TestlMax 

# and then returns to its caller with 0 as a successful 

# Result. On failure, it returns 1 as a failing Result. 

10 # Assume that the tests MyFunctionalTestl Min, ... all 

# return a Result of 0 (Pass), 1 and 2 (for a couple 

# of levels of failure). The Transition Matrix of the 

# finite state machine implemented by FlowTestl is: 

15 #. Result 0 Result 1 Result 2 

« ■ » 

# 

# FlowTestl_Min FlowTestl JTyp return 1 return 1 

# FlowTestlJTyp FlowTestl JVfax return 1 return 1 

# FlowTestlJMax return 0 return 1 return 1 
20 # 

# where the Allowables run by each Flowltem are: 

# Flowltem IFlowable that is run 

# FlowTestl_Min MyFunctionalTestl Min 

# FlowTestlJTyp MyFunctionalTest 1 Typ 

25 # FlowTestlJMax MyFunctionalTestlMax 

# 

Flow FlowTestl 
{ 

Flowltem FlowTestlJMin MyFunctionalTestl Min 
30 { 

Result 0 

{ 

Property PassFail = "Pass"; 
IncrementCounters PassCount; 
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GoTo FlowTestl_Typ; 

} 

Result 1,2 

{ 

Property PassFail = "Fail"; 
IncrementCounters FailCount; 
Return 1; 

} 



} 



Flowltem FlowTestlJTyp MyFunctionalTestlTyp 
{ 

» 

Result 0 

{ 

15 Property PassFail = "Pass"; 

IncrementCounters PassCount; 
GoTo FlowTestl_Max; 

} 

20 Result 1,2 

■ 

{ 

Property PassFail = "Fail"; 
IncrementCounters FailCount; 
Return 1; 

25 } 

} 



# Likewise for FlowTestl_Max 

Flowltem FlowTestl_Max MyFunctionalTestlMax 
30 { 

Result 0 

{ 

Property PassFail = "Pass"; 
IncrementCounters PassCount; 
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Return 0; 



} 



Result 1,2 

{ 



} 



Property PassFail = "Fail"; 
IncrementCounters FailCount; 
Return 1 ; 



15 



20 



25 



30 



# 

# FlowTest2 is similar to FlowTestl . It implements a 

# finite state machine for the Min, Typ and Max flavors 

# of MyFunctionalTest2. On success it tests Test2Min, 

# Test2Typ, Test2Max and then returns to its caller with 

# 0 as a successful Result. On failure, it returns 1 as 

# a failing Result. 
# 

# Assume that the tests MyFunctionalTest2Min, ... all 

* 

# return a Result of 0 (Pass), 1 and 2 (for a couple 

# of levels of failure). The Transition Matrix of the 

# finite state machine implemented by FlowTest2 is: 
# . 



# 
# 



Result 0 



Result 1 



Result 2 



# FlowTest2_Min 

# FlowTest2_Typ 

# FlowTest2_Max 
# 



FlowTest2_Typ 
FlowTest2_Max 
return 0 



return 1 return 1 

return 1 return 1 
return lreturn 1 



# Where the IFlowables run by each Flowltem are: 

# Flowltem IFlowable that is run 
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# 
# 
# 



FlowTest2_Min 
FlowTest2_Typ 
FlowTest2 Max 



Flow FlowTest2 



{ 



} 



MyFunctionalTest2Min 
MyFunctionalTest2Typ 
MyFunctionalTest2Max 



10 



15 



20 



25 



30 



# 

# Now the FlowMain, the main test flow, can be presented. It 

# implements a finite state machine that calls FlowTestl 

# and FlowTest2 as below: 



# 



Result 0 



Result 1 



# FlowMain_l FlowMain_2 return 1 

# FlowMain_2 return 0 return 1 
# 

# Where the IFlowables run by each FloWltem are: 

# . Flowltem IFlowable that is run 



# 
# 



FlowMain_l 
FlowMain 2 



FlowTestl 
FlowTest2 



Flow FlowMain 



{ 



# The first declared flow is the initial flow to be 

# executed. It goes to FlowMain_2 on success, and 

# returns 1 on failure. 
Flowltem FlowMain 1 FlowTestl 



{ 



Result 0 



{ 



Property PassFail = "Pass"; 
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IncrementCounters PassCount; 
GoTo FlowMain_2; 

} 



10 



30 



Result 1 

{ 

# Sorry ... FlowTestl failed 
Property PassFail = "Fail"; 
IncrementCounters FailCount; 



# Add to the right soft bin 

SetBin SoftBins."3 GHzSBFTFail"; 



Return 1; 



15 } 



} 

Flowltem FlowMain_2 FlowTest2 
{ 

Result 0 

20 { 

# All passed! 

Property PassFail = "Pass";- 
IncrementCounters PassCount; 

25 # Add to the right soft bin 

SetBin SoftBins."3GHzAllPass"; 



Return 0; 



} 



Result 1 

{ 

# FlowTestl passed, but FlowTest2 failed 
Property PassFail = "Fail"; 
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IncrementCounters FailCount; 



# Add to the right soft bin 

SetBln SoftBins."3GHzCacheFail"; 



Return 1; 



} 



} 

} 



TestFlow = FlowMain; 

The above test plan is structured as follows in a preferred order: 

1. First, a version number is provided. This number is used to ensure 
compatibility with the compiler version. 

15 2. Then, a number of imports are declared. These are various files with 

declarations needed in order to resolve names used in the test plan. 

3. Next, the Test Plan name is declared, after which come the inline declarations 
of the test plan. 

4. Next a set of PListDefs are declared. These include file-qualified names 
20 naming GlobalPLists from the named files. They also include Pattern List 

variables. Pattern List variables are variables that can be initialized in custom 
flowables at execution time. They provide a means of delaying binding tests to 
actual pattern lists until runtime: 

5. Next, a set of UserVars is declared. These include a string. 

25 6. Some Counters are then declared, to determine the number of tests passed and 

failed. Counters are simply variables that are initialized to zero, and 
incremented at IncrementCounter statements. They are different from Bins 
described earlier which have the semantics that only the currently set bin is 
incremented at the end of the test of a DUT. 

30 7. Next, a series of Test Conditions is declared. Each of these specifies a Test 

Condition Group and a selector. In this example, the Test Condition Groups 
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come from mytestconditionsgroups.tcg. However, they could have been inline 
in the test plan. 

■ 

8. Next, a series of Flowables or Tests is declared. Each of this is known Test 
FunctionalTest which selects a Pattern List and a test condition. Thus for 
instance, MyFunctionalTestlMax selects the test condition TClMax and a 
pattern list. 

9. Following this, three flows are declared, FlowTestl, FlowTest2 and FlowMain. 
Flows run Flowables, Flowables include Tests (such as 
MyFunctionalTestlMax) and other flows (such as FlowTestl and FlowTest2). 
Each of FlowTestl and FlowTest2 run through the minimum, typical and 
maximum versions of Test 1 and Test2 respectively. The flow FlowMain calls 
the earlier declared flows, FlowTestl and then FlowTest2. 

10. Finally, the TestFlow event is assigned to the FlowMain Flow. Thus the flow 
FlowMain is the one that will be executed by this test plan when a user chooses 
to Execute this plan. 

C++ for Flows 

With the above rules, a C++ implementation can be done for most of the 
elements, with the exception of the Flows themselves. ( 

C++ for Flowltems 

The C++ class to represent a Flowltem may have the following interface: 

An operation 

Status setFlowable(IFlowable* pIFlowable); 

which will set the IFlowable that will be executed for this Flowltem. 

Once the Flowltem returns from the set of calls needed to execute this IFlowable, 
it will need to increment a list of counters depending on the Result value. To this end, the 
Flowltem needs to have a vector of counters that is to be incremented. This is initialized by a 
call: 

Status setCoiinterRefs(unsigned int result, 

CounterRefList counterRefs); 
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Calling this sets up a vector of references to counters into the Flowltem, so that it can increment 
them once the IFlowable completes execution. For example, the statement 

IncrementCounters A, B, C; 

* 

would preferably use the above call as follows: 
// Somewhere earlier 
CounterRefList counters; 



// Code for Result clause 
// Result 2, 3 {...} 
10 //offlowObject 

counters.resetO; 
counters.add(&A); 
counters.add(&B); 
counters.add(&C); 
15 flowObject.setCounterRefs(2, counters); 

flowObject.setCounterRefs(3, counters); 

A temporary CounterRefList object named counters is used. Initially 
counters.reset() is called, followed by a number of counters.addO calls to set up the counters list. 
This is then used to setup the vector of counter addresses to be updated for result values 2 and 3. 

20 The Flowltem may then need to transition to another Flowltem on a particular 

result: 

Status setTransition(unsigned int result, Flowltem* pFlowItem); 

Several such calls will naturally need to be made in the case that a certain Result clause deals 
with many result values. 

25 The Flowltem may need to return a result. This is done by: 

Status setReturnResult(unsigned int result, 

unsigned int returnResult); 

For example, for the Flowltem FirstFlowItem in the previous example, the above 
would be called with the value "2" for "result* ■ and "1" for "returnResult". 
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Finally, the Flowltem needs an operation to execute: 

Status execute(unsigned int& result, Flowltem* pNextFlowItem); 

This operation will execute the IFlowable, then update the indicated counters, 
and then either return a Result, or a pointer to the next Flowltem. If this pointer is NULL, then 
5 the result is the returned value. 

« 

The code.that would be generated for Flowltem FlowMain_J is as follows: 



Flowltem FlowMainJ ; 
Flowltem FlowMainJ2; 

1 0 CounterRefList counters; 



FlowMain_l .setFlowable(FlowTestl); 



// Result 0 

15 counters.resetQ; 



counters . add(&PassCount) ; 
FlowMainJ ,setCounterRefs(0, counters); 
FlowMainJ ,setTransition(0, &FlowMainJ2); 



20 // Result 1 

counters.resetQ; 



counters.add(&FailCount); 

FlowMainJ .setCounterRefs(l , counters); 



25 // The following call from ITestPlan will set the 

// current bin group and bin name. 
pTestPlan^setBin("SoffBins", "3GHzSBFTFail"); 
FlowMainJ .setReturnResult(l, 1); 

The code generated above sets up FlowMainJ to run the IFlowable 
30 "FlowTestl", and then sets it up to increment the appropriate list of counters for each result, and 
finally to take the necessary actions. The necessary action in the case of result "0" is a 
transition to FlowMainJ, and in the case of result "1" is a return. 
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C2. Counter Support in a TestPlan 



Counters are variables that are initialized to zero, and can be incremented by an 
IncrementCounter statement at various points during a test run. They are different from Bins, 
which are incremented only at the end of the test. Furthermore, bins are hierarchical while 
5 counters are simple variables. Thus, counters are a much simpler and more limited facility than 
bins. 

Counters can be supported in a TestPlan via a member of a Counters class that 
maintains a set of named counters which are unsigned integers. Objects will be defined in this 
class via a Counters declaration. Counters will not be automatically reset when a test starts, thus 
1 0 allowing a TestPlan to gather counts over testing many DUTs. Methods will be provided to 
reset, increment and query the value of a counter. This enables an alternative to binning in 
order to determine counts as a result of running a test. 

The TestPlan preferably contains a member variable, mjtnodifiedCounters, 
which is the set of counters modified by running the test on a DUT. This set is initialized to the 
1 5 empty set at the start of the test. At each place an IncrementCounters call is made, code will be 
generated to add the named counters to the m_modifiedCounters member. Thus, this member 
gathers together all the counters that were modified during the execution of a test on a DUT. 

OH- for the Flow Ob j ect 

Once all the Flowltems have been created, the Flow object can be created as a 
20 C++ obj ect as shown below: 

An operation to add a Flowltem 

Status addFlowItem(FlowItem* pFlowItem, bool isInitalFlowItem); 

which will add the indicated Flowltem to the Flow. The boolean is set to True 
if this is the initial Flowltem of the Flow. 

25 An operation to execute the Flow 

Status executeFlow(unsigned int& result); 

This will preferably return when the Flow returns, with the result of executing 
the flow. The action of this is to start executing the flow with the initial Flowltem. It will keep 
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executing Flowltems as long as the current Flowltem returns a next Flowltem to execute. When 
the current Flowltem returns a Result, then this operation completes with that Result. 

Hence, the C++ code generated for a Flow has several repeated calls to 
addFlowItemO ^ order to add Flowltems to the Flow. The executeFlowO operation will occur 
when this Flow in the Test Plan is selected for execution. 

C3. test Classes 

In general majority of the program code is data for device test, and the rest is the 
code of test program, which realizes the test methodology. This data is DUT-dependent (e.g., 
power supply conditions, signal voltage conditions, timing conditions, etc.). The test code 
consists of methods to load the specified device conditions on to ATE hardware, and also those 
needed to realize the user specified objectives (such datalogging, etc). 

As explained above, to increase the reusability of test code, such code should be 
independent of any device-specific data (e.g., pin name, stimulus data, etc.), or device-test- 
specific data (e.g., conditions for DC units, measurement pins, number of target pins, name of 
pattern file, addresses of pattern programs, etc.). If code for a test is compiled with data of these 
types, the reusability of the test code would decrease. Therefore, any device-specific data or 
device-test-specific data should be made available to the test code externally, as inputs during 
code execution time. 

In the open architecture test system, a Test Class, which is an implementation of 
the ITest interface, realizes the separation of test data and code (and hence, the reusability of 
code) for a particular type of test. Such a test class could be regarded as a "template" for 
separate instances of it, which differ from each other only on the basis of device-specific and/or 
device-test-specific data. Test classes are specified in the test plan file. Each Test class 
typically implements a specific type of device test or setup for device test. For example, 
Functional, AC and DC Parametric tests are preferably implemented by separate Test classes. 
However, custom test classes can also be used in test plans. 

Test classes allow the user to configure class behavior by providing parameters 
that are used to specify the options for a particular instance of that test. For example, a 
Functional Test will take parameters PList and TestConditions, to specify the Pattern List to 
execute, and the Level and Timing conditions for the test, respectively. Specifying different 
values for these parameters (through the use of different "Test" blocks in the test plan 
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description file) allows the user to create different instances of a Functional Test Figure 5 
shows how different test instances 502 would be derived from a single test class 504. 

These classes should be designed to allow the compiler 400 to take the 
description of the tests and their parameters from the test plan file and generate correct C++ 
5 code, which can be compiled and linked to generate the test program. Test class instances may 
be added to objects describing test flow to create a complex execution sequence of device tests. 

C4. Derivation from ITest and IFlowable 

As mentioned above, Test classes derive from ITest. With the above rules, these 
can be implemented in C++ classes that implement the ITest interface. In addition to the 
1 0 methods specified for the ITest interface, these classes provide the Test-specific intelligence and 
logic required to perform specific classes of device test. Test classes also implement the 
IFlowable interface. As a consequence of this, instances of Test classes can be used in 
Flowltems to run tests. 

Customization 

15 Customization mechanisms are provided to allow users to call C functions, and 

develop their own classes implementing the ITest and IFlowable interfaces. 

Introspection Capability 

If an object of a Test class could be interrogated regarding its methods and 
signatures, then it could be verified that the appropriate parameters are available for inclusion in 

20 the generated source code. Such a feature would be very useful for error checking and 

validation during the translation phase. If the test engineer made a mistake in the names of 
parameters, or the number (or possibly the types) of arguments to these parameters, the 
translation phase could catch it and provide a meaningful error message at translation time 
instead of waiting for a compile-time error message from the C++ compiler. This would be 

25 more useful to the test engineer. 

Introspection refers to the ability to ask an object to look within itself and return 
information regarding its attributes and methods. Some languages, such as Java, provide this 
ability as a part of the language. Other languages, such as Visual Basic, impose such a 
requirement on objects intended to be used with it. C++ makes no provisions for this feature. 
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This method also lends well to providing for default parameter values, as well as 
indications of optional parameters. In addition, if this capability is provided as a part of the 
implementation of all Test classes, then GUI applications could also use this information to 
dynamically build up dialogs and other user interface elements to help engineers make effective 
5 use of these classes. 

These complexities are offset in an embodiment of the invention through a 
mechanism that provides, in lieu of full introspection, a method that allows the Test class 
developer to fully specify, in a single text-based source file (per Test class), the public 
methods/attributes of the Test class that the developer has designated as the ones required to 
1 0 parameterize the class. 

A single source is preferred: one would not want to have the description of the 
parameterization interface of a Test class in one file, and the C++ interface description in 
another independent (header) file, and then be burdened with the need to keep both sources 
synchronized. Towards this end, the "text-based" description is embedded in a pre-header file 
15 for the Test class, which is used by the compiler for limited introspection, as well for generating 
the C++ header for the Test class. The generated C++ header file is the one used to finally 

* 

compile the Test class C++ code. 
The Pre-Headers 

The use of headers in C++ is well known. Because C++ is difficult to parse and 
20 read, however, an embodiment of the invention defines a syntax allowing the compiler to create 
a C++ output which can be used as a header by a test class developer. According to this 

■ 

embodiment, the test class developer writes a pre-header, which is output by the compiler 400 
as a header file, allowing visibility into the corresponding test classes or other test entities. 

The following example illustrates the concept of the pre-header file for a Test 
25 class in accordance with the preferred embodiment of the present invention. Consider the 
following excerpt from a source file, with a test FuncTestl : 

TestCondition TCI 
{ 

30 TestConditionGroup = TCG1 ; # Previously defined TCG for Levels 

Selector = min; 
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} 



TestCondition TC2 

{ 

TestConditionGroup = TCG2; # Previously defined TCG for Timing 
Selector = min; 

} 



Test FunctionalTest FuncTestl 
10 { 

PListParam = patListl ; # Previously defined pattern list 

TestConditionParam = TC 1 ; 
TestConditionParam = TC2; 

} 

1 5 The compiler needs to know what a FunctionalTest entails in order to determine 

whether the declaration of FuncTestl above is legal. Rather than building in the knowledge of a 
FunctionalTest into the compiler, the definition of what a FunctionalTest entails can be 
specified in the Pre-Header. 

Assume that FunctionalTest is a C++ class having base classes Testl and Test2, 
20 and having members which are a PList, and an array of TestConditions. The compiler needs to 
know about the types of the members of FunctionalTest in order to recognize that the above 
declaration of FuncTestl is legal. 

Furthermore, in order to generate a C++ object declaration for FuncTestl, a C++ 
header for the class FunctionalTest needs to be constructed. This requires compiler to also 
25 know about the base classes of the FunctionalTest class, the names of its members and other 

* 

such information. 

The pre-header sub-language of an embodiment of the invention provides the 
compiler with the information it needs to both recognize the legality of declarations, and to 
generate C++ headers and object declarations that correspond to declaration. 

30 Note that a FunctionalTest is a simple type (as far as parameterization is 

concerned), and thus, would use quite a simple description for parameterization. One could thus 
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write a pre-header, FunctionalTest.ph, that supports the above parameterization as follows 
(assume that pre-headers are available for the base test classes Testl and Test2): 

1 Version 1 .0; 

2 # 

5 3 # Parameterization specification pre-header for FunctionalTest 

4 # 

5 Import Test l.ph; # For base class Testl 

6 Import Test2.ph; # For base class Test2 

7 TestClass = FunctionalTest;# The name of this test class 
10 8 PublicBases = Testl , Test2;# List of public base classes 

9 # The parameters list or "parameter block": 

10 Parameters 

11 { 

12 # The following declaration specifies that a FunctionalTest has 
15 13 # - a parameter of typePList 

14 # - [represented by C++ type Tester: :PatternTree] 

15 # - stored in a member named m_j)PatList 

16 # - a function to set it named setPatternTree. 

17 # - a parameter description for the GUI to use as a tool tip 
20 18 PList PListParam 

19 { 

20 Cardinality » 1; 

21 Attribute = m_pPatList; 

22 SetFunction = setPatternTree; 

25 23 Description = "The PList parameter for a FunctionalTest"; 

24 } 

25 # 

26 # The following declaration specifies that a FunctionalTest has 

27 # - 1 or more parameters of type TestCondition 

30 28 # - [represented by C++ type Tester: :TestCondition] 

29 # - stored in a member named inJestCondnsArray 

30 # - a function to set it named addTestCondition. 

31 # - a parameter description for the GUI to use as a tool tip 

32 # The [implement] clause causes the translation phase of to 
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33 # generate a default implementation of this function. 

34 # 

35 TestCondition TestConditionParam 

36 { 

5 37 Cardinality =l-n; 

38 Attribute = mJestCondnsArray; 

39 SetFunction = addTestCondition [Implement]; 

40 Description = "The TestCondition parameter for a 
FunctionalTest"; 

10 41 } 

42 } 

43 # 

44 # The section below is part of the Pre-Header which is an escape 

45 # into C++ code. This will be referred to as a "template block." 
15 46 # 

47 # Everything in this section will be reproduced verbatim in the 

48 # generated header file, except for "$Class", "$Inc", 

49 # "SParamAryTypes", "$ParamAttrs", "SParamFns" and "$ParamImpls". 

50 # 

20 51 # Note that no comments beginning with the character are supported 

52 # within the following section. 

53 # 

54 CPlusPlusBegin 

55 Sine 

■ 

25 56 namespace 

57 { 

58 class SClass 

59 { 

60 // Array types for parameters storage: 
30 61 SParamAryTypes 

62 public: 

63 virtual void preExecO; 

64 virtual void execQ; 
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66 



65 



virtual void postExecO; 
SParamFns 



67 



68 private: 



70 



69 



double m_someVar; 
SParamAttrs 



71 



72 }; 



73 



74 SParamJmpls 

75 } // End namespace 



76 CPlusPlusEnd 



C++ For Parameterized Test Classes 



As the compiler processes a pre-header file, it builds up the values of the 



compiler variables such as Sine, $Class, SParamAryTypes and others. This enables it to then 
create the following C++ header by generating the C++ code above verbatim, and expanding in 
the values of the compiler variables Sine, $Class, etc. at the indicated places. For 
FunctionalTestph, it creates the following C++ header file FunctionalTest.h for the 
FunctionalTest class. 



1 #line 7 "./FunctionalTestph" 

2 #include <ITest.h> 

3 #line 5 "./FunctionalTestph" 

4 #include<Testl.h> 

5 #line 6 "./FunctionalTestph" 

6 #include <Test2.h> 

7 #line 55 "./FunctionalTest.ph" 

8 #include <vector> 

9 #line 55 "./FunctionalTestph" 

10 #include <Levels.h> 

11 #line 55 "VFunctionalTestph" 

12 #include <TestCondnGrp.h> 
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13 ... 

14 #line 56 "./FunctionalTestph" 

15 namespace 

16 { 

17 #line 7 "./FunctionalTestph" 

18 class FunctionalTest : public ITest, 

19 #line 8 "./FunctionalTestph" 

20 public Testl, 

21 #line 8 "./FunctionalTestph" 

22 public Test2 

23 #line 59 "./FunctionalTest.ph" 

24 { 

25 // Array types for parameters storage: 

26 #line 61 "./FunctionalTestph" j 

27 public: 

28 #line 37 "./FunctionalTest.ph" 

29 typedef std::vector<Tester::TestCondition *> 
TestConditionPtrsAryJ; 

30 #line 62 "./FunctionalTest.ph" 

31 public: 

32 virtual void preExecO; 

33 virtual void execO; 

34 virtual void postExecO; 

35 public: 

36 #line 7 "TFunctionalTestph" 

37 void setName(OFCString &name); # Automatic for all tests 

38 #line 22 "./FunctionalTest.ph" 

39 void setPatternTree(PatternTree *); 

40 Mine 23 "7FunctionalTest.ph" 

41 String getPListParamDescriptionO const; 

42 #line 39 "./FunctionalTest.ph" 

43 void addTestCondition(TestCondition *); 

44 #line 40 "./FunctionalTestph" 

45 void getTestConditionParamDescriptionO const; 
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46 #line 67 "./FunctionalTestph" 
47 

48 private: 

49 double m__someVar; 

50 #line 70 "./FunctionalTestph" 

51 private: 

52 #line 7 "./FunctionalTestph" 

53 OFCString mjaame; # Automatic for all tests 

54 #line 21 "./FunctionalTestph" 

55 Tester: :PatternTree *m jpPatList; 

56 #line 38 "./FunctionalTestph" 

57 TestConditionPtrsAryJ: m_testCondnsArray; 

58 #line 71 "./FunctionalTest.ph" 

59 • • • 

60 }; 

61 ... 

62 #line 7 "./FunctionalTestph" 

63 inline void 

64 #line 7 "./FunctionalTest.ph" 

65 FunctionalTest::setName(OFCString &name) 

66 #line 74 "VFunctionalTesth" 

67 { 

68 mname = name; 

69 return; 

70 } 

71 #line 39 "./FunctionalTest.ph" 

72 inline void 

73 #line 39 "./FunctionalTest.ph" 

74 FnnctionalTest::addTestCondition(TestCondition *arg) 

75 #line 74 "./FunctionalTestph" 

76 { 

77 m_testCondnsArray .pushback(arg) ; 

78 return; 
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79 } 



80 #line 23 "./FunctionalTestph" 

81 inline void 

82 Tester: : String FunctionaITest::getPListParamDescriptiohO 

83 { 

84 return "The PList parameter for a FunctionalTest"; 

85 } 

86 #line 40 "./FunctionalTestph" 

87 inline void 

88 Tester : : String FunctionalTest: : getTestConditionParamDescriptionO 

89 { 

90 return "The TestCondition parameter for a FunctionalTest"; 

91 } 

92 #line 75 "./FunctionalTestph" 

93 } // End namespace 



As described earlier, this pre-header enables the compiler to check the validity of 
a FunctionalTest declaration, to generate code for it, and to generate a C++ header that would be 
needed by it. 

As an example, consider the FunctionalTest declaration given earlier, reproduced 
below for convenience: 

Test FunctionalTest FuncTestl 
{ 

PListParam = patListl ; # Previously defined pattern list 

TestConditionParam = TCI; 
TestConditionParam = TC2; 

} 

The C++ header that would be generated for this by the compiler is given above. 
The compiler would generate the following code for the above FunctionalTest construct: 

FunctionalTest FuncTestl; 
FuncTestl .setName("FuncTestl "); 
FuncTestl .setPatternTree(&patListl); 
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* 

FuncTestl .addTestCondition(&TCl); 
FuncTestl .addTestCondition(&TC2); 

Notice also the name that is generated for the Description function. Each 
parameter named Xxx is associated with a member function: 

5 Status getXxxDescriptionQ const; 

■ 

that returns the string with a description for the tool tip that the GUI can use. 
Other Pre-Header Features 

The pre-header supports some other user defined enumerations as an additional 
type. This allows the GUI to provide a drop down list of possible choices that could be used for 

1 0 setting the value of a particular parameter. Furthermore, the pre-header provides a feature to 
associate a number of parameters that can be thought of as a table. For example, it may be 
convenient to implement an array of "properties" as an associated set of an array of strings for 
the names, and an array of integers for the values. One easy way of implementing this feature is 
to use an array of custom types (discussed later). However, that requires the user to write a 

15 custom type pre-header to use. Both of these features are illustrated in the following example: 



« 

# 

# File FooBarTest.ph 



# 



20 



# Parameterization specification pre-header for 

# custom test class FoobarTest 



Version 1.0; 



25 



Import Testl .ph; # For base class Testl 

TestClass = FoobaiTest; # The name of this test class 
PublicBases = Testl ; # List of public base classes 



30 



# The parameters list: 



Parameters 
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# An enumerated type 

Enum WishyWashy = Yes, Perhaps, Possibly, Maybe, MaybeNot, No; 

# Define a WishyWashy parameter. 
WishyWashy WW 

{ 

Cardinality = 1 ; 
Attribute = m_ww; 
SetFunction « setWw; 

Description == "The WW parameter for a Foobar Test"; 

} 

# This class has an array of name-number pairs that is 

# interpreted in the class. 
ParamGroup 

{ 

Cardinality = 0-n; 

# The Name field in this array is: 

# - of type String 

# - [represented by C++ type Tester: : String] 

# - stored in a member named m_NameArray 

# - a function to set it riamed addName. 

# - a parameter description for the GUI to use as a tool tip 
String Name 

{ 

Attribute = m_NameArray; 
SetFunction = addName; 
Description = "A Name with a Value"; 

} 



# The Number field in this array is: 

# - of type Integer 
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# - [represented by C++ type int] 

# - stored in a member named mJNumberArray 

# - a function to set it named addNumber. 

# - a parameter description for the GUI to use as a tool tip 
Integer Number 

{ 

Attribute = mjNumb er Array ; 
SetFunction = addNumber; 
Description = "The value of the Name"; 

} 

} 

# The following declaration specifies that a FunctionalTest has 

# - a parameter of typePList 

# - [represented by C++ type Tester: :PatternTree] 

# - stored in a member named m_pPatList 

# - a function to set it named setPatternTree. . 

# - a parameter description for the GUI to use as a tool tip 
PList PListParam 

{ 

Cardinality = 1; 
Attribute = m_pPatList; 
SetFunction = setPatternTree; 

Description = "The PList parameter for a FunctionalTest"; 

} 
# 

# The following declaration specifies that a FunctionalTest has 

# - 1 or more parameters of type TestCondition 

# - [represented by C++ type Tester: :TestCondition] 

# - stored in a member named m_testCondnsArray 

# - a function to set it named addTestCondition. 

# The [implement] clause causes the translation phase of to 

# generate a default implementation of this function. 
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# 

TestCondition TestConditionParam 
{ 

Cardinality = 1-n; 
Attribute = m_testCondnsArray; 
SetFunction = addTestCondition [Implement]; 
Description = "The TestCondition parameter for a 
FunctionalTest"; 

} 

CPlusPlusBegin 
Sine 

namespace 
{ 

class SCIass 
{ 

// Array types for parameters storage: 
SParamAryTypes 

public: 

virtual void preExecO; 
virtual void exec(); 
virtual void postExecO; 
$ParamFns 

//... 

private: 

double m_someVar; 
SParamAttrs 

// ... 

}; 

// ... 

SParamlmpls 
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} // End namespace 
CPlusPlusEnd 

It must be noted that a custom type name-number pairs could have been declared, 
and a single array parameter of that custom type could have been used to have the same effect as 
the above ParamGroup of parameters. The technique presented above is a convenience that 
avoids the necessity of declaring a custom type. 

C5. Custom Function Declarations 

This allows the user to call custom functions when a flow transition takes place. 
Custom functions are declared through pre-header as follows: 

# File MyFunctions.ph 
# 

# Parameterization specification pre-header for MyFunctions 
Version 1.0; 

Functions = MyFunctions; # The name of this group of functions 

# Declare the following C++ function in the 

# MyFunctions namespace to determine the minimum 

# of two values. 

# // Return the minimum of x, y 

# double MyRoutines: :Min 

# (TTestPlan* prTestPlan,int& x, int& y); 
Integer Min(Integer x, Integer y); 

# Declare the following C++ function in the 

# UserRoutines namespace to return the average of 

# an array. 

# // Return the average of the array 

# double MyRoutines: : Avg 
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# (TTestPlan* pITestPlan, double* a, const int a_size); 

* 

# The C++ function will be called with a and a'Length 
Double Avg(DoubIe aQ); 

# Declare the following C++ function in the 

# UserRoutines namespace to print the dut id 

# and a message 

# // Return the average of the array 

# double MyRoutines: :Print 

# (TTestPlan* pITestPlan, String* msg, unsigned int& dutld); 

# The C++ function will be called with a and a'Length 
Void Print(String msg, Unsignedlnteger dutld); 

Typically a C++ section needs to be provided for the above declarations, as the 
compiler will expand these declarations in a standard way. The user is of course responsible for 
the C++ implementation of these functions. Note that all of the above functions will presumably 
take an ITestPlan pointer as an implicit first parameter. This pointer provides the function 
writer access to stateS in the TestPlan. For instance, the function writer could use the ITestPlan 
interface to access the current Flow, the current Flowltem in the flow, the current Result clause, 
values of UserVars, and other such information. Certain tester defined functions are available 
for use in the file Functions.ph: 

Version 1.2.3; 
# 

25 # File Functions.ph 

# 

Functions = Functions; # The name of this group of functions 

# Declare the following C++ function in the 
30 # Functions namespace 

# Returns the ID of the current DUT being tested by the 

# caller. 



5 



10 
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Unsignedlnteger GetDUTIDO; 
C++ for Custom Function Declarations 

The C++ code that would be generated by compiler for MyFunctions above is to 
simply declare some functions in the MyFunctions namespace: 

namespace MyFunctions 

{ 

double Min(TTestPlan* pITestPlan, int& x, int& y); 

double Avg(TTestPlan* pITestPlan, double* a, const int a_size); 

void PrintOTestPlan* pITestPlan, char* Msg, unsigned int dutID); 

} 

* 

These functions will be callable from a flow. 
C6. Custom Flowables 

It is also possible to create a pre-header implementing the C++ BFlowable 
interface using the pre-header. This enables a user to define custom flowables that can be run in 
a Flowltem. Shown below is a pre-header for the user-defined Flowable MyFlowable: 

■ 

# 

# File MyFlowable.ph 
# 

# Parameterization specification pre-header for MyFlowable 
# 

Version 1.2,4; 

Flo wableClass = MyFlowable; # The name of this custom class 



# The parameters list: 
Parameters 

{ 

# The following declaration specifies that a MyFlowable has 

# - 1 optional parameter Intl of type Integer 
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# - [represented by C++ type int] 

# - stored in a member named mjnt 1 Val 

# - a function to set it named setlnt 1 Val . 
Integer Int 1 

{ 

Cardinality = 0-1; 
Attribute = m_intl Val; 
SetFunction = setlnt 1 Val; 

} 



10 



# The following declaration specifies that a MyFlowable has 

# - 1 mandatory parameter Int2 of type Integer 

# - [represented by C++ type int] 

# - stored in a member named mjnt2Val 
15 # - a function to set it named setfcit2Val. 

Integer Int2 

{ 

Cardinality = 1; 
Attribute = m_int2Val; 
20 SetFunction = setlht2Val; 

} 

# The following declaration specifies that a MyFlowable has 

# - one or more parameters of type String 

# - [represented by C++ type Tester: :String] 
25 # - stored in a member named m_stringArrVal 

# - a function to set it named addStringVal. 
String Stringltem 

{ 

Cardinality = 1-n; 
30 Attribute = m_stringArrVal; 

SetFunction « addStringVal; 

} 



# The following declaration specifies that a MyFlowable has 
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# - A single PList parameter 

# - [represented by the C++ type Tester: :PList] 

# - stored in a member named m_plist 

# - a function to set it named setPListParam 
5 PList PListParam 

{ 

Cardinality = 1; 
Attribute = mjriist; 
SetFunction = setPListParam; 

10 } 

} 



# 

# The section below is part of the Pre-Header which is an escape 
15 # into C++ code. 

# 

# Everything in this section will be reproduced verbatim in the 

# generated header file, except for "SClass" "Sine", 

# "SParamAryTypes" "SParamAttrs", "SParamFns" and "SParamlmpls". 
20 # 

# Note that no comments beginning with the '#' character are supported 

# within the following section. 
# 

CPlusPlusBegin 
25 $Inc 

namespace 

class SClass . 

■ . » 

30 // Array types for parameters storage: 

SParamAryTypes 
public: 

■ 

virtual void preExecO; 
virtual void execQ; 



WO 2004/072670 



PCT/JP2004/001649 



122 

virtual void postExecO; 
SParamFns 

//... 
private: 

double m_someVar; 

$ParamAttrs 

// ... 

}; 

//... 

SParamlmpls 

} // End namespace 
CPlusPlusEnd 

There are several classes implementing the DFlowable interface. These include: 

1 . Flows for program loading which will check whether a test plan can be 
executed within the current tester configuration. 

2. Flows for pattern loading which will load specific patterns and pattern lists. 

3. Flows for initialization which will put hardware and software in a known state, 
load global variables, and do other initialization and validation functions. 

4. Other generally useful test flows. 
C7. Custom Types 

The discussion on Test class parameterization earlier only allowed for test class 
parameters to be of known types, viz., elementary types and tester-defined types such as PLists, 
and TestConditions. For user flexibility, it is important to provide type extensibility, whereby 
types (that are unknown a~priori to the compiler) can be created and used. Custom types (CTs) 
will be defined in the Custom Types. These can be used to define types corresponding to 
language structs (also referred to as Plain Old Data types, or PODs, which are quite different 
from their namesakes in C++) as well as for types corresponding to C-language typedefs for 
function signatures. A separate file with user types will have the extension .ctyp. Here is an 
example of a user types declaration in accordance with the preferred embodiment of the present 
invention: 
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# File MyCustomTypes.ctyp 
# 



Version 1 .0.0; 



CustomTypes 

{ 

# A structured Plain-Old-Data type 
Pod Foo 

10 { 

String SI; # String is a standard type 
Integer II; #... and so is Integer 
String S2; 

} 

15 

# Another structured type using Foo 
Pod Bar 

{ 

Foo Fool; 
20 String SI; 

Foo Foo2; 

} 



# 

25 # A pointer to a function. 



# Return type: Integer 

# Parameters: Integer, Integer 
# 

Routine BinaryOp(Integer, Integer) Returns Integer; 

# 

# Another pointer to a function. 

# Return type: Void 

# Parameter: Integer 
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# 

Routine UnaiyOp(Integer) Returns Void; 

# 

5 # A pointer to a function that takes 

# no parameters and does not return a value. 
# 

Routine NullaiyOpO Returns Void; 

} 

10 

C++ for Custom Types 

The CustomTypes declaration presented above will be translated by the compiler 
into the following C++ code: 

namespace CustomTypes 
15 { 

struct Foo 

{ 

Tester: :String SI; 

int II; 

20 Tester::String S2 

}; 

struct Bar 
{ 

Foo Fool; 
25 Tester: :String SI; 

Foo Foo2; 

}; 

typedef int (*BinaiyOp) (int&, int&); 

■ 

typedef void (*UnaryOp)(int); 
30 typedef void (*NullaryOp)0; 

} 

Objects of these types can be passed to Test classes as parameters, as shown next. 
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Using Custom Types as Test Class Parameters 

Consider the case where the user has an extension to a test, which needs to be 
initialized with — in addition to pattern lists and test conditions — other class objects, as well 
as arbitrary (i.e., user-defined) objects that are defined within a file containing Custom Types 
5 (i.e., a .ctyp file). For example, suppose the user wants to use the CTs defined in the file 
MyTestCTs.ctyp: 

# File MyTesetCTs.ctyp 
Version 1.0; 

10 CustomTypes 

{ 

Pod Foo 

{ 

String name; 

15 PList patternList; 

} 



Pod Bar 

{ 

20 Foo someFoo; 

Double dVal; 

} 



Routine BinaryOpQLnteger, Integer) return Integer; 



25 } 



All that the user needs to do to use the above types is import the above file in his 
test class pre-header. Since the compiler interprets CTs that are so defined, the definitions for 
Foo and Bar are therefore available to it when it is processing the test class pre-header. 
Moreover, the compiler defines two C-language structs, struct Foo and struct Bar, 

30 corresponding respectively to the types Foo and Bar above, the definitions for which are placed 

» 

in the file myTestCTs.h. The Import statement for myTestCTs.ctt causes the file myTestCTs.h 
to be #include-d in the generated test class C++ header. The following example illustrates this 
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process. First, consider the declaration for the test in the test plan (the declarations for pattern 
lists and test conditions have been omitted for clarity): 

• • • 

Import MyFunctions.ph; 
Import MyCustomTypes.ctyp; 

• • • 

# The CustomVars block defines variables of the Custom 

# types defined earlier. 

» 

CustomVars 

{ 

# • * 

Bar bar 1 = 

{ 

{ "This is a Foo", somePatList }, # someFoo 
3.14159 #dVal 

} 
# 

V 

# A function object that is a binary operator. 

# The name on the right hand side of the assignment 

# is a, routine declared in MyFunctions, for which, 

# of course, the user has to provide an implementation. 

.# . 

BinaryOp bopl = MyFunctions. Min; 

} 

... 

Test MyFancyTest MyTestl 
{ 

... 

BarParam = barl; 
Binary OpParam = bopl; 

} 
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In the above example, a CustomVars block is included in a test plan. A separate 
file with customization variables will have the extension .cvar. The user would write a pre- 
header for MyFancyTest that supports the above parameterization as follows (the 
parameterization declarations for pattern lists and test conditions have been omitted for clarity): 

# 

# File MyFancyTestph 
# 

# Parameterization specification pre-header for MyFancyTest 
# 



10 



Version 1.0.2; 



Import MyCustomTypes.ctyp; # For CTs used in MyFancyTest 
Import FunctionalTestph; # For base class FunctionalTest 
15 TestQass = MyFancyTest; # The name of this test class 

PublicBases = FunctionalTest; # List of public base classes 

# The parameters list: 
Parameters 
20 { 

# The following declaration specifies that a MyFancyTest has 

# -an optional array of parameters of custom type Bar 

# - [represented by C++ type CustomTypes: :Bar] 

# - stored in a member named m_barsArray 
25 # - a function to set it named addBarParam. 

# An implementation will be generated for addBarParam. 
Bar BarParam 

{ 

Cardinality = 0-n; 

* 

30 Attribute = m_bars Array; 

SetFunction = addBarParam [Implement]; 

} 



# The following declaration specifies that a MyFancyTest has 
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# - an optional parameter of custom type BinaryOp 

# - [rqpresented by C++ type CustomTypes: :BinaiyOp] 

# - stored in a member named m_binaryOp 

# - a function to set it named setBinaryOpParam. 

5 # An implementation will be generated for setBinaryOpParam. 

BinaryOp BinaryOpParam 

{ 

Cardinality = 0-1; 

■ 

Attribute = m_binaryOp; 
1 0 SetFunction = setBinaryOpParam [Implement] ; 

} 

} 



15 CPlusPlusBegin 



20 



Sine 

namespace 

{ 



class SClass 
{ 

$Par amAr yTyp es 
public: 

25 virtual void preExecO; 

virtual void execO; 
virtual void postExecO; 
SParamFns 

//... 

30 private: 

double m_someVar; 
SParamAttrs 

II... 

}; 
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II... 

SParamlmpls 

} // End namespace 
CPlusPlusEnd 

C++ for Custom Test Classes using Custom Types 

Finally, once the compiler has processed this pre-header file, it will create the 
following C++ header file for the MyFancyTest class, MyFancyTesth: 

#include <My CustomTypes .h> 
#include <ITest.h> 
#include <FunctionalTest.h> 
• 

namespace 

{ 

class MyFancyTest : public ITest, 

public FunctionalTest 

{ 

public: 

typedef std::vector<CustoiiiTypes::Bar *> BarAry_t; 

public: 

virtual void preExecO; 
virtual void execO; 
virtual void postExecO; 

public: 

void sefName(OFCString &name); # Automatic for all tests 

void setPatternTree(PatternTree *); 

void addTestCondifion(TestCondition *); 

void addBarParam(CustomTypes: :Bar *); 

void setBinaryOpParam(CustomTypes: :BinaryOp *); 

99 • 

private: 
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double m_someVar; 
private: 

OFCString m_name; # Automatic for all tests 
PatternTree *m_pPatList; 
TestConditionPtrsAry J m_testCondns Array; 
BarAry_t m_barsArray; 
BinaryOp *m_binaryOp; 



}; // End class MyFancyTest 



inline void 

MyFancyTest: :addBarParam(CnstomTypes: :Bar *arg) 
{ 

mjbars Arr ay.push_back(ar g) ; 
15 return; 

} 

inline void 

MyFancyTest::setBinaryOpParam(CustomTypes::BinaryOp *arg) 

{ 

20 mJbinaryOp = arg; 

return; 

} 

} // End namespace 



25 C8. Parameterization 



As seen above, a pre-header for a Test class, custom Flowable class, or custom 
function definitions offers limited introspection into the class/functions through a 
parameterization specification section. The compiler uses this section to generate the 
parameterization interface for the class/function (and generate the class/function header itself). 
30 For Test classes and Flowable classes, it also uses this section to subsequently generate the calls 



WO 2004/072670 PCT/JP2004/001649 

131 

in the Test Plan code to initialize an instance of that class. The following points concerning pre- 
headers and corresponding declaration should be noted: 



1 . Every Test or custom Flowable class definition is preferably specified in a pre- 
header. The Parameters block in the pre-header is preferably the only place 
where the parameters list for such a class can be specified. (Thus, as a corollary, 
the "standard" parameters for a Test, such as pattern list and test condition 
specifications, also need to be included in the pre-header' s Parameters block; 
this allows all parameters, standard and CTs, to be treated uniformly.) 

2. All parameters defined as non-optional (i.e., with a non-zero cardinality) in the 
pre-header for a Test or Flowable class should be initialized in the Test block or 
Flowable block declaration for an instance of that class. 

3. The objects used for initialization of parameters in the Test/Flowable block 
should have been defined previously. 

4. The replacement indicators $Class, $Inc, SParamAryTypes, SParamFns, 
SParamAttrs and SParamlmpls must appear at the exact locations within the 
user code section of the pre-header that the user intends the corresponding 
generated code to be inserted at in the generated class header file. These should 
appear exactly once, since specific code is generated for each. 

5 . The name of a parameter specification in the Parameters block of the pre-header 
(such as PListParam, TestConditionParam or BarParam in the examples above) 
is the name of the parameter to be used in the declaration of an instance of that 
class. 

6. The following are the semantics of the descriptors used in a parameter 
specification: 

a. Cardinality: This indicates the number of parameters of this type that 
will be supported. The following are the possible values in one 
embodiment: 
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i. 1: This parameter is mandatory, and should be specified exactly 
once. This parameter will be maintained as a pointer to an 
object of the type of the parameter. 

ii 0-1 : This parameter is optional; if specified, it must be 
specified only once. This parameter will be maintained as a 
pointer to an object of the type of the parameter. 

■ 

iii 1-n: This parameter is mandatory. Moreover, multiple values 
can be specified for this. The values will be stored in the order 
of specification. 

iv 0-n: This parameter is optional. Multiple values can be 
specified for this. The values will be stored in the order of 
specification. 

Note that for 0 and 0 above, all specified values will be stored in an 
STL vectoro, templated on a pointer to the type of the parameter. The 
type of this vector will be defined and inserted at the point indicated by 
$ParamAryTypes. The access level for these type definitions is always 
public. 

Attribute: The name of the C++ variable to use as the store for 
parameter value(s) of this type. The name will be reproduced verbatim, 
as a private data member of the C++ class, and must conform to the 
requirements for a C++ identifier. Note that the type of this attribute is: 

i. A pointer to the type of the parameter, if only single values are 
permitted; 

ii. An STL vectoro, templated on a pointer to the type of the 
parameter, if multiple values are permitted (see 0 above). 

Note that the attributes hold references to objects created and populated 
by the Test Plan, and do not own these objects. The lifetime of the 
objects are always managed by the Test Plan itself. 

SetFunction: The name of the function to use for setting a value for this 
parameter. The following points should be noted: 
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» 

i. The name will be reproduced verbatim, and hence, must 
conform to CH- language requirements. 

ii. The access level of the function is always public. 

iii. The return type is always void. 

5 iv. The function always takes only a single argument, of type 

pointer-to-parameter-type. 

Note that a value is always set singly; i.e., for parameters that allow specification 
of multiple values, the generated code in the Test Plan will call this function repeatedly, once 
for every value specified, each of which will be added to an STL vector (as described above). 

10 The optional keyword "[implement]" following the function name indicates that 

a trivial implementation for this function will be made available as an inline method in the class 
header (inserted at the point indicated by SParamlmpls). Otherwise, the user is responsible for 
providing an implementation of the function. 

d. Description: A string literal that is a tooltip which will be used by a 

1 5 GUI tool to provide help during runtime modification of this parameter. 

* 

The C++ member function generated in the custom class for a 
parameter named Xxx will be 

String getXxxDescription 0 const; 

The function will return the specified string. 

20 Test Plan Example with Customization 

Shown below is the test plan example embellished with some customization: 



# 



# File MyCustomizedTestPlan.tpl 
# 



25 



Version 0.1; 



# Imports as before ... 



30 
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# The following import is implicit, but can be explicitly 

# provided. 

Import FunctionalTestph; 

# Import for MyFlowables, MyFunctions and Functions 
Import MyFlowables.ph; 

Import MyFunctions.ph; 
Import Functions.ph; 

# Start of the test plan 

# 

TestPlan Sample; 

* 

# This block defines Pattern Lists file-qualified names and 

# Pattern List variables that are used in Test declarations. 

# The file-qualified names refer to pattern lists in the named 

# files. The variables refer to String variables which will 

# hold the pattern list names at run time. User defined Flowable 

# objects could set the values of these variables through an 
#API. 

PListDefs 

{ 

# File qualified pattern list names 
pi 1 A.plist:patl Alist, 
pl2A.plist:pat2AList, 

# Pattern list variables 
plistXxx, 
plistYyy, 

plistZzz 

} 
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# SocketDef, UserVars declaration as before ... 

# Declarations of TestConditions TClMin, TClTyp, TClMax, 

# TC2Min, TC2Typ, TC2Max as before ... 

# 

# Declare a FunctionalTest "FunctionalTest" refers to a C++ 

# test class that runs the test, and returns a 0, 1 or 2 as 

# a Result. The Test Condition Group TCG1 is selected with 

# the "min" selector by referring to the TClMin TestCondition. 
# 

# Note that compiler can compile this because of the imported 

# FunctionalTest.ph file. 
# 

Test FunctionalTest MyFunctionalTestlMin 
{ 

PListParam = patl AList; 
TestConditionParam = TClMin; 

} 
# 

# Additional FunctionalTest declarations for the following, as before 

# MyFunctionalTestlTyp 

# MyFunctionalTestlMax 

# MyFunctionalTest2Min 

# MyFunctionalTest2Typ 

# MyFunctionalTest2Max 
# 

# Here is a declaration of MyFlowable. It uses a PatternList variable 

# plistXxx which is initialized by the flowable prior to use here. 
# 

# Compiler can compile this because of the imported MyFlowables.ph file: 
Flowable MyFlowable MyFlowable 1 
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} 
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Intl = 10; 
Int2 = 20; 

Stringltem = "Hello World"; 
PListParam = plistXxx; 



# Counters for PassCount and FailCount as before ... 



10 



15 



# Flows as before. Flows FlowTestl and FlowTest2 are 

# unchanged from the previous example. 
Flow FlowTestl 



{ 



} 



20 



25 



30 



Flow FlowTest2 



{ 



} 
# 

# Now FlowMain, a main flow, can be presented. It 

# implements a finite state machine that calls FlowTestl 

# and FlowTest2 as below: 



# 
# 
# 



Result 0 



Result 1 



# FlowMain_l FlowMain_2 return 1 

# FlowMain_2 FlowMainJ3 return 1 

# FlowMain_3 FlowMain_4 return 1 

# FlowMain_4 FlowMain_5 return 1 

# FlowMain_5 return 0 return 1 
# 

# Where the IFlowables run by each Flowltem are: 
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# 

# Flowltem IFlowable that is run 



# 



# FlowMain_l MyFlowablel 

5 # FlowMain_2 DatalogStartFlow 

# FlowMain_3 FlowTestl 

# FlowMain_4 FlowTest2 

# FlowMain_5 DatalogStopFlow 

10 FlowFlowMain 

{ 

# The first declared flow is the initial flow to be 

# executed. It goes to FlowMain_InitializationFlow 
15 # on success, and returns 1 on failure. 

# 

Flowltem FlowMain_l MyFlowablel 

{ 

Result 0 

20 { 

Property PassFail = "Pass"; 
IncrementCounters PassCount; 
# A user function call 

MyFunctions.Print ('Tassed MyFlowable 1 " 

25 Functions.GetDUTTDO); 

GoTo FlowMain_2; 

} 



Result 1 

30 { 



Property PassFail = "Fail"; 
IncrementCounters FailCount; 
# A user function call 

MyFunctionsJPrintOTailed MyFlowablel", 
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Functions.GetDUTIDO); 
SetBin Sofffiins."3GHzLeakage"; 

Return 1; 

} 

} 
# 

# Goes to FlowMain_3 on success 

# and returns 1 on failure. 
# 

Flowltem FlowMain_2 DatalogStartFlow 
{ 

Result 0 
{ 

Property PassFail = "Pass"; 
IncrementCounters PassCount; 
# A user function call 

MyFunctions.Print("Passed DatalogStartFlow", 

* 

Functions.GetDUTIDO); 

GoTo FlowMain_3; 

} 

Result 1 

{ 

Property PassFail - "Fail"; 
IncrementCounters FailCount; 
MyFunctions J>rint('Tailed DatalogStartFlow", 

Functions.GetDUTIDO); 

Return 1; 

} 

} 

# This Flowltem calls the previously defined FlowTestl 
Flowltem FlowMain_3 FlowTestl 
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{ 

Result 0 

{ 

Property PassFail = "Pass"; 
IncrementCounters PassCount; 

# A user function call 
MyFunctions-PrintCTassed FlowTestl 

Functions.GetDUTIDO); 

GoTo FlowMain_4; 

} 

Result 1 

{ 

Property PassFail = "Fail"; 

i 
i 

IncrementCounters FailCount; 

# A user function call 
MyFvmctions.Print('Tailed FlowTestl", 

Functions.GetDUTIDO); 
SetBin SoftBins."3GHzCacheFail"; 

Return 1; 

} 

} 

# This Flowltem calls the previously defined FlowTest2 
Flowltem FlowMain _4 FlowTest2 

Result 0 

{ 

Property PassFail = "Pass"; 
IncrementCounters PassCount; 

# A user function call 
MyFunctions.PrintC*Passed FlowTest2", 

Functions.GetDUTIDO); 

GoTo FlowMain_5; 
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} 

Result 1 

{ 

# FlowTestl passed, but FlowTest2 failed 
Property PassFail = "Fail"; 
IncrementCounters FailCount; 

# A user function call 
MyFunctions.PrintC'Failed FlowTest2", 

Functions.GetDUTIDO); 
SetBin SoffBins."3GHzSBFTFair; 
Return 1; 

} 



Flowltem FlowMain_5 DatalogStopFlow 

{ 

Result 0 

{ 

# All Passed! 

Property PassFail = "Pass"; 
IncrementCounters PassCount; 

# A user function call 
MyFunctions-PrintCTassed all!", 

Functions.GetDUTIDO); 
SetBin Sofffiins."3GHzAUPass"; 

Return 0; 

} 

Result 1 

* 

{ 

# FlowTestl and FlowTest2 passed, 

# but DatalogStopFlow failed 
Property PassFail = "Fail"; 
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IncrementCounters FailCount; 
# A user function call 

MyFunctions .Print("Failed DatalogStopFlow", 

Functions.GetDUTIDO); 

Return 1; 

} 

} 

} 



1 0 The following points need to be noted about the above code: 

1 . The PListDefs section here has some PList names and also some PList variables. 
The PList names are names that can directly be used in tests. The PList 
variables are variables which can be used in tests, and whose value is bound at 
runtime to actual PLists by code in a customized Flowable. 

15 2. The PListDefs section is optional. If not present, its contents will be inferred 

by compiler from the various Test declarations. If present, it must declare all of 
the used PList parameters of Tests, though it may declare more. 

m 

3. A runtime API will be available to assign values to PList variables. The 
TestPlan class will have a function: 

20 Status SetPListVariable(const Tester: : String& varName, 

const Tester: :String& fileQualifiedPListName); 
The Flowable will be able to use the above function to bind a PListVariable to a 
particular PList. 

4. User functions and functions can be called in Flowltems just prior to a 

25 transition, which is either a transfer of control to another Flowltem, or a return. 

C++ for User Function Calls 

With the exception of invoking custom function calls in flows, C++ code that 

■ 

would be generated by the compiler has been shown for the various customization techniques 
presented earlier. User function calls in a Flowltem are preferably handled by an IUserCalls 
30 member of each Flow. Each Flow preferably has a member of the interface IUserCalls which 
exports a single virtual member function, as shown below: 
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class IUserCalls 

{ 

public: 

virtual void exec(const String& flowItemName, 
5 unsigned int result) = 0; 

}; 

When a Flow with user function calls is encountered, the Flow gets populated 
with an instance of a class that implements the above interface. For example, in FlowMain in 
the example in the flow will be populated with an instance of the following class: 

10 class FlowMain_UserCalls : public IUserCalls 

{ 

public: 

virtual void exec(const String& flowItemName, 

unsigned int result) 

15 { 

if (flowItemName = "FlowMainJ ") 
{ 

» 

//... 

} else if (flowItemName — "FlowMain_2") 
20 { 

//... 

} else if (flowItemName = "FlowMain_3") 
{ 

switch (result) 

25 { 

case 0: 

MyFunctions::Print('Tassed FlowTestl", 

Functions::GetDUTBD0); 

return; 

30 case 1: 

MyFunctions::PrintCTailed FlowTestl", 

Functions::GetDUTID0); 

return; 
default: 
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return; 

} 

} 

else if (flowItemName = "FlowMain_4") 
5 { 

//... 

} 

else if (flowItemName = "FlowMain_5") 
{ 

10 //... 

} 



} 



}; 



1 5 The Flowltem: :execute() operation knows the name of the flow item. Before it 

returns with the pointer to the next flow, it will call XUserCalls::exec() for the enclosing flow, 
passing its own flow item name, and the value of the current result. This will cause the above 
code to be executed, invoking the needed user defined functions. 

C9. Test Program Compilation 

20 As explained above, the Test Plan description file specifies the objects used in a 

test plan and their relationships to one another. In one embodiment, this file is translated to the 
C++ code that will be executed on the Site Controller in the form of an implementation of a 
standard interface ITestPlan. This code can be packaged into a Windows dynamic link library 
(DLL) which can be loaded onto the Site Controller. The Test Program DLL is generated to 

25 have standard known entry points that the Site Controller software can use to generate and 
return the TestPlan object it contains. 

Construction from a Test Plan Description 

The process of conversion from a test plan description to an implementation of 
ITestPlan is accomplished by the test program compiler 400. This process occurs in two phases: 
30 translation and compilation. 
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In the translation phase 402, the compiler 400 processes a test plan file (and the 
various other files it imports), as well as the pre-headers for all the test types used in the test 
plan. In this phase, it creates the C++ code for the Test Plan object and the C++ headers for the 
test types encountered, along with all other supporting files, such as MSVC++ (Microsoft 
5 Visual C++) workspace and project files, DLL "boilerplate" code, etc. The compiler 400 inserts 
file and line directives into the generated code to ensure that compile-time error messages refer 
back to the appropriate location in the description file instead of pointing into the generated 
code. 

In the compilation phase, which occurs after the compiler has created the 
10 necessary files, a standard compiler 404, such as an MSVC++- compiler, is invoked to compile 
the files and link them into a DLL. 

The compiler takes, as input, a valid test plan file (and*all related files), and 
generates, as necessary, a TestPlan file and all other files represented by "Import" directives in 
the test plan file. In addition, it generates a MSVC++ "Solution" to build the Test Plan DLL. 
1 5 For example, if the main file (MyTestPlan.tpl) included Timingl .tim to incorporate timing 
information, then the compiler would create (among others) the following files: 

MyTestPlan.h 
MyTestPlan.cpp 
Timing l.cpp 

20 MyTestPlan.sln (MSVC++ "Solution" file) 

MyTestPlan.vcproj (MSVC++ "Project" file) 



After all files are created (or updated), the compiler invokes the MSVC++ 
application, specifying the "Solution" it created, and builds the DLL. Any errors and/or 
25 warnings would be shown to the user. 

If, after building the Test Plan, the user made a change to Timingl .tim, the user 
would then invoke the compiler, passing it MyTestPlan.tpl. The compiler would recognize (by 
timestamp information) that the main test plan file is unchanged, so that MyTestPlan.h/.cpp 
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would not be recreated. However, while processing the main test plan file, it would see that the 
Timing.tim file has changed. Therefore, it would recreate the Timingl .cpp file, and invoke the 
MSVC++ application to rebuild the DLL. This avoids recompiling MyTestPlan.cpp, and only 
compiles Timingl. cpp and re-links the DLL. This approach will be especially useful in cutting 
5 down re-compile and re-link times for large test plans that take a significant amount of time to 
compile. 

D. Running the Test Program 

r 

The Site Controller software loads the Test Program DLL into its process space 
and calls a "factory" function within the DLL to create an instance of the Test Plan object. 
10 Once the Test Plan object has been created, the Site Controller software can then execute the 
test plan or interact with it in any other way necessary. 

Non-Interactive Builds 

To most C++ software developers in the Windows environment building an 
application (or a DLL, or Library, etc) means bringing up a development environment (MS 
15 Visual C++, Borland C++, or similar), editing code, and (often) pressing a button to build the 
product 

The test environment of an embodiment of the invention will have a similar set 
of activities. Test Plan developers will need to edit code and build their Test Plans. However, 
tester will not require the Test Plan developer to bring up a C++ development environment in 
20 order to produce the resulting Test Plan DLL. 

In order to accomplish this the present invention employs the concept of a non- 
interactive build. A non-interactive build is defined as a build that uses MS Visual C++ in a 
non-interactive mode. Note that this still allows other tools to be used interactively to manage 
such a build., The only implication is that Visual C++ is used non-interactively. 

25 Assumed Environment 

Certain assumptions are made about the user's environment. The assumptions 

are: 

1 . The Test Plan developer will be developing his Test Plan according to above 
methods and rules. 
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2. The Test Plan developer may not have a expert level knowledge of C++. 

3. The Test Plan developer will have access to command-line tools or GUI tools to 
convert file(s) to a Test Plan DLL. 

Building Applications Without Buttons 

5 Working with MS Visual Studio non-interactively requires one of two. 

approaches. The first (and simplest) is to use the command-line interface. The second (and 
more flexible) is to use the Automation interface. This section describes both approaches. 

Creating the Pr o j ect 

In order to use Visual Studio non-interactively one should start with a working 
10 Solution which contains one or more valid Projects. Unfortunately, this is the one task that 

cannot be accomplished from either a command-line or Automation approach. Neither method 
provides a mechanism for project creation. However, projects and solutions for Visual Studio 
can be created from a template. Therefore, given a project name and a template to start from we 
can create a solution/project for Visual Studio. 

1 5 Populating the Proj ect 

Adding new files to the produced project uses the Visual Studio Automation 
model since the command-line does not support this. We provides two Visual Studio macros to 
add new and existing files to a project. Similar code could be used by an external script using 
an ActiveScript Engine (such as VBScript, JScript, ActivePerl, ActivePython, etc) to perform 
20 the same tasks.Therefore, our code generation tools could create new files and, using the 

Automation Model, add them to the existing Visual Studio project. After the files are created 
they can be updated as necessary by the tools. 

» 

Building the Project 

Once we have a solution and project in place there are several options to using 
25 Visual Studio non-interactively to build the Test Plan. The simplest option is to invoke it from 
the command-line. Such a command-line would look like: 

devenv solutionFile /build solutionCfg 
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where solutionFile is a Visual Studio solution file and solutionCfg is a specific configuration 
applicable to the projects within the solution. Another solution is to use the Visual Studio 
Object Model for Automation. This allows a finer grain of control over the build and 
configuration process. As mentioned above, it contains a listing of a Perl script to build a project 
5 from the command line. This program reads a configuration file which specifies projects and 
configurations to build (as well as other information about the projects) and builds them all 
using the Automation Model, Look at the uses of the $msdev object in this script for examples 
of how to use Automation objects in a script. 

■ 

Debugger Support 

10 In order for developers of Test classes to verify and debug their work, they need 

access to a debugger that allows them to break into the Site Controller and step through their 
code. Since the code generated by the compiler is C++ which is compiled by MSVC++, we use 
the MSVC++ debugger to debug Test class implementations. Note that this feature is meant 
only for Test class developers or others who work directly in C++. Other mechanisms will be 

1 5 provided to test engineers who wish to debug or step through the operation of a Test Program 
without referring directly to the generated C++ code. 

System Software Environment 

This section describes the general software environment for the Tester: the 
locations for the files required by user test plans, mechanisms for specifying alternate locations 
20 for such files, and the methods for specifying the locations of the test plans and module control 
software. 

Environment Required by Test Plans 



System standard locations, as well as the runtime configuration of the search 



paths for 



25 1 . pattern lists, 

2. patterns, 

3. timing data, and 

4. test class DLLs 
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required by a test plan, may be configured by "environment" variables, as specified by 
environment configuration files. These are text files, with a simple syntax such as: 

TesterJPATOBJJPATH = "pattems\data;D:\projects\SC23\patterns\data" 

The advantage of having such "environments" defined in text files instead of 
5 through native OS-supported environment variables is that the implementation is then not 
limited by the common restrictions that OS-supported environment variables have, such as 
maximum string lengths, etc. The following "environment" (setup) variables will be used for the 
entities listed above: 

Pattern lists: Tester_PATLIST_PATH. 
1 0 Pattern object files: Tester_PATOB JPATH. 

Pattern source files: TesterJPATSRCJPATH (this is optional; please see). 

Timing data files: Tester JITMINGJPATH. 

Test class DLLs: Tester_TEST_CLASS_LIBPATH. 

15 In order to support special cases, while maintaining useful default behavior, we 

provide three levels of configuration. These are described in increasing order of precedence: 

First, a system environment setup file, 
$Tester_INSTALLATION_ROOT\cfg\setups\Setup.env, will specify the default values of 
"environment" variables. If no other configuration mechanism is available, this file will be 

20 required. In general, it will be available for all test plans run on the system. This file is created 
by the Installation and Configuration Management (ICM) system during installation, with input 
from the installer to assign the default values for the three variables mentioned above. (Note 
that besides the system defaults for the above three variables, this file will also contain the 
system defaults for certain other tester "environment" variables, as described in the following 

25 sub-section.) 

Second, an environment setup file may be specified by the user as a runtime 
argument to the test plan. The variables in this runtime configuration will take precedence over 
default definitions. 
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Finally, a test plan may use a special block to specify the environment variables 
to be used in its execution. Variables defined in the test plan will take precedence over those in 
the default system file or the user-defined file. 

In general, all necessary variables should be defined through one of the 
5 mechanisms described above. If a variable is not defined, a runtime error will occur. 

4 

Other Environment Setups 

Besides the "environment" variables that are required by user test plans, the 
following two "environment" variables are required by the test environment: 

1. Tester_TEST_PLAN_LIBPATH: This specifies the search path that 
10 the System Controller will use for finding a user test plan DLL that 

should be loaded. Note that the same search path will also be used for 
finding user pin description and socket files. The default value for this 
variable, specified during installation time to the ICM, is stored by the 
ICM in the file $Tester_INSTALLATION_ROOT\cfg\setups\Setup.env. 

15 2. Tester JVEODULEJLBPATH: This specifies the search path that the 

system will use to load vendor-provided hardware module control 
software DLLs. This information, extracted from the Configuration 
Management Database (CMD), is also stored in the file 
$Tester_BSfSTALLATION_ROOT\cfg\setups\Setup.env by the ICM. 

r 

20 Note that while a user can override the value given in the Setup.env file for the 

Tester JTESTJPIANJLIBPATH variable, the value given in the Setup.env file for the 
Tester MODULE LD3P ATH should not be changed by the user unless the user wants to 
explicitly change the search path for the vendor-provided hardware module control software 
DLLs. 

25 Search Path Specification Semantics 

The following points should be noted about the "environment" variables that 
specify search paths: 

1 . Each should be a semicolon(";")-separated list of directory names that 
the system will search to find a referenced file of a particular type. 
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2. After initial system lookup of the value of such an "environment" 
variable, any changes made by the user to its value (for example, by 

v . editing an environment configuration file) will only be registered by the 

system when the user explicitly "informs" the system of the need to do 
5 so. 

3 . Relative pathnames in the search paths will be interpreted as being 
relative to a particular setting of a related environment variable (that 
provides the functionality of defining a root), as paths relative to the 
"current working directory" (CWD) could lead to ambiguous results, 

* 

10 since the notion of a CWD in a distributed environment — such as the 

one in which the tester works — might not be what the user intuitively 
expects it to be. This related environment variable, which designates 
the root that all relative pathnames in the search paths will be assumed 
to be relative to, is the "Tester_INSTALLATIONJROOT" variable, 

15 which gives the location of the top-level (i.e., "root") directory of the 

tester installation on a user's system. 

4. The directory entries cannot contain the characters in the set 
[V:*?"o|;]; note that except for the semicolon (";"), all the other 
characters in this set are illegal in Windows file names. The semicolon 

a 

20 (";") should not be used in search path entries, since it is used to 

i 

demarcate entries in the search path. Note that pathnames can have 
embedded whitespaces, but all whitespaces occurring immediately 
before and after a pathname (i.e., before the first and after the last non- 
whitespace character in the pathname) will not be considered to be part 
25 of the pathname, and will be ignored. 

5. The search path directories will be searched in the order they are 
encountered in the definition. The first occurrence of a file will be the 
one chosen. 
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E. Test Patterns 

The efficient management, handling and loading of a very large set of test pattern 
files is an important architectural aspect of the framework of an embodiment of the invention. 
The idea of hierarchical pattern lists is regarded as being an effective tool in providing tractable 
conceptualization and ease of use of the system to the end user. 

The stimulus to a DUT is made available to the test system through test vectors. 
Vectors can generally be categorized as sequential (or linear), scan or Algorithmic Pattern 
Generator (APG)-derived. In the system of an embodiment of the invention, test vectors are 
organized in terms of patterns that are applied to the DUT at test time. A pattern is represented 
by a Pattern object in the user's test program. Id the system, patterns are organized in pattern 
lists, represented programmatically by pattern list objects. A Pattern List object represents an 
ordered list of patterns or other pattern lists. The ordering is implicit in the order of declaration 
of the list components. Note that if only a single pattern is needed, it is required to be 
encapsulated in a list by itself. 

A pattern list object in the user's test program is associated with a pattern list file 
on disk, which contains the actual definition of the pattern list. The contents of a pattern list are 
thus dynamically determined by the contents of the associated disk file (more will be said about 
this later). 

The definition of a pattern list provides an explicit name for the pattern list, and 
identifies an ordered list of patterns and/or other pattern lists through file name associations. It 
also provides for the specification of execution options, which will be described in detail after 
the pattern objects have been described, since the options can be applied to both pattern lists and 
patterns. The pattern list should follow the following rules: 

file-contents : 

version-info global-pattern-list-definitions 

version-info : 

Version version-identifier ; 

global-pattern-list-definitions : 
global-pattern-list-definition 

global-pattern-list-definitions global-pattern-list-definition 
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global-pattern-list-definition : 

global-pattern-list-declaration { list-block } 

global-pattern-list-declaration : 

GlobalPList pattern-list-name options opt 

list-block : 
list-entry 

list-block list-entry 

list-entry : 

pattern-entry ; 
pattern-list-entry ; 
global-pattern-list-definition ; 
local-pattern-list-definition ; 

pattern-entry : 

Pat pattern-name options opt 

pattern-list-entry : 

PList pattern-list-reference options opt 

pattern-list-reference : 

pattern-list-qualified-name 

file-name ': 'pattern-list-qualified-name 

pattern-list-qualified-name : 
pattern-list-name 

pattern-list-qualified-name '. 'pattern-list-name 

local-pattern-list-definition : 

local-pattern-list-declaration { list-block } 

local-pattern-list-declaration : 

LocalPList pattern-list-name options op t 

options : 
option 

options option 

option : 

[ option-definition ] 
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♦ 

option-definition : 

option-name option-parameters opt 

option-parameters : 
option-parameter 

option-parameters V option-parameter 
The following are the descriptions of undefined non-terminals used above: 

* 

1 . version-identifier : A sequence of one or more characters from the set [0-9.], 
where the first character must be a digit, 

2. name : A sequence of one or more characters from the set [a-zA-Z_0-9], where 
the first character must be from the set [a-zA-ZJ. 

3. pattern-list-name : A sequence of one or more characters from the set [a-zA- 
Z_0-9], where the first character must be from the set [a-zA-Z_J. 

4. file-name : A valid Windows file name (must be enclosed in double quotes if 
any white-spaces are contained in the file name). Note that this should be a 
simple file name, i.e., it should not have a directory component. A pattern-list- 
reference can be either internal referring to a pattern list in the same file, or 
external referring to one in another file. External references need to be 
qualified by a file-name, 

5. option-name : A sequence of one or more characters from the set [a-zA-Z_0-9], 
where the first character must be from the set [a-zA-Z_J. 

6. option-parameter : A sequence of one or more characters from the set [a-zA- 
Z>9]. 

Pattern list files support comments, which are meant to be ignored by a pattern 
list file parser. Comments start with the character, and extend to. the end of the line. 

El. Rules for Pattern List 

t 

The static or compile-time rules for pattern lists govern the declaration and 
resolution of names. Names in the pattern list language are declared by global-pattern-list- 
definitions and local-pattem-list-definitions. They are referenced by pattern-list-references. 

■ 

Below are some rules governing these declarations and references. 
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10 



15 



1. 



2. 



A global-pattern-list-definition or a local-pattern-list-definition declares the 
name of a pattern list. A pattem-list-reference references the name of a 
declared pattern list The names of global pattern lists are globally known. The 
names of local pattern lists are known only in die list-block in which they are 
declared. They can be referred to without qualification direcfly in that list block. 
In a more deeply nested declaration, a local pattern list will need to be referred 
to by a qualified name. 

Local pattern list names are known within the scope of an enclosing pattern list, 
and global pattern list names known within the scope of the system For 
example: 

GlobalPList Gl 



{ 



LocalPList LI 



{ 



LocalPList L2 
{ 



} 



20 



GlobalPList G2 
{ 



25 



} 



} 



PList L2; 
PList G2 



# OK. Name L2 is known in this scope 

# OK. Name G2 is global 



30 



PList L2; 
PList LI .L2; 



PList Gl XI X2; 



PList G2; 



# Error. Name L2 is not known here. 

# OK. Name LI is known here. L2 is known by 

# qualification. 

# OK. Qualification by Gl is not needed but 

# is allowed. 

# OK. Name G2 is global 
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} 

3. Global pattern lists may be defined at an outermost level in a pattern list file, or 
may be defined as nested within an enclosing pattern list. The nesting is merely 
a convenience, however. They are conceptually defined as global pattern lists 
at the outermost level in the file. A nested global pattern list is semantically 
equivalent to an outermost (non-nested) global pattern list of the same name. 
So for example: 

GlobalPList Gl 
{ 

* 

GlobalPList G2 ... 

} 

is semantically equivalent to: 
GlobalPList Gl 

{ 

PList G2; # References G2 

} 

GlobalPList G2 ... 

4. All global pattern lists are uniquely named. 

GlobalPList Gl 
{ 

# Note that this is as if declared at the outermost level 

# with a reference to it right here. 
GlobalPList G2 

{ 

... 

} 

} 

# This declaration will be an error in this or any other file, 

# as the name G2 is already taken. 
GlobalPList G2 # Error. Global name G2 is taken. 

{ 
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} 

5. Local pattern lists are always have their definitions nested within an enclosing 
pattern list which also determines the scope of the name of the local pattern list 
Local pattern lists are uniquely named within their enclosing pattern list. Local 
pattern lists are syntactically disallowed from occurring at the outermost level 
in a pattern list file. 

GlobalPListGl 
{ 

LocalPList LI 

{ 

LocalPList L2 

{ 

LocalPList LI # OK. No local name LI is declared 
directly 

# in the enclosing scope defined by L2. 

{ 
} 



PList LI ; # OK. Refers to LI declared in L2 
PList G1.L1; # OK. Refers to LI declared in Gl. 

} 

# Error. Redeclaring name LI when the enclosing scope 

# defined by Gl already has an LI declared in it. 
LocalPList LI; 

{ 
} 



} 



WO 2004/072670 



157 



PCT/JP2004/001649 



■ 

6. Each pattern list file contains the definition for one or more global pattern lists. 

w 

This follows directly from the syntax. The outermost level is a global-pattern- 
list-definition, and there must be at least one of them. 

7. The pattern-name is a reference to a pattern, following the Pat keyword. It 
references a pattern that is in a pattern file whose name is obtained by 
concatenating a suffix .pat to the pattern name. The file denotes a file that will 

* 

be obtained along a search path defined for patterns. 

8. A pattern-list-reference is a reference to a pattern list following the PList 
keyword. The reference consists of an optional filename followed by a 
qualified pattern list name which is just a list of names separated by dots. So, 
for instance, the following could be a pattern-list-reference: 

PList foo.plist:Gl.Ll.L2.L3; 

referring to a local pattern list L3 nested in L2 nested in LI nested in a global 
pattern list Gl that is in a file foo.plist. The leftmost name segment in the above 
name is Gl. 

The leftmost name segment must resolve to either a global pattern list, or else to 
a local pattern list that is visible from the point of reference. 

Name resolution of a pattern-list-reference proceeds as follows: 

1 . Each name segment resolves to a name declared in the context of the 
prefix before it 

2. If there is a file qualification, the leftmost name segment resolves to a 
global pattern list declared in the named file, 

3. If there is no file qualification, the leftmost name could resolve to a 
local pattern list within the enclosing scope and if that fails then the 
next enclosing scope, and so on, up to an enclosing global scope. 

4. Limiting the searching of scopes to the closest enclosing global scope is 
needed in order to preserve the semantics of global scopes as if they 
were declared at the outermost level in the pattern list file. If the nested 
global scope was (equivalently) textually declared at the outermost 
level, the name resolution search would terminate after examining its 
scope. 
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5. If the reference has not been resolved by the prior steps, then the 
leftmost name segment can be resolved to a global pattern list withi 
this same file. 

6. If the reference has not been resolved by the prior steps, then the 
leftmost name segment can be resolved to a global pattern list named in 
the file by adding the .plist suffix to the leftmost name segment. 

7. If the reference has not been resolved by the prior steps, then the 
reference is in error. 

As mentioned earlier, the above rules dictate that the leftmost name segment 
resolves to either a local pattern list that is visible from the point of reference, or else to a global 
pattern list. 

The following example illustrates some of these ideas. 

GlobalPlistGl 
{ 

PList G3; # OK. Refers to a pattern list later in this file. 
PList G4; # OK. Refers to a pattern list in file "G4.plist" 



# OK. Refers to Gl in the file "my_plists.plist'\ 
PList myj>lists.plist:Gl; 

# OK. Refers to a pattern list in file "my_plists.plist". 

The 

# qualified name refers to a local pattern list named L2 
declared 

# in the scope of a local pattern list named LI declared in 

the 

# scope of a global pattern list named Gl . 
PList my_plists.plist:Gl .LI .L2; 



LocalPList LI 
{ 
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LocalPListL2 

{ 
} 

} 

PList LI; # OK. Refers to LI declared in the 
# enclosing scope of Gl 



10 



} 



GlobalPlist G2 
{ 

LocalPList L2 
{ 

15 } 



GlobalPList G3 
{ 

LocalPList L3 



20 { 

} 



PList LI; # Error. No LI declared in this or any enclosing 
# scope; 

25 

# Error. The name L2 is not declared in this scope. Also 

D 

# though L2 is declared in the enclosing scope, this scope 

# is global, and so no further enclosing scope is examined. 
# 

30 # Contrast with reference to name L2 in LocalPList L3 below. 

PList L2; 



PList G1.L1; # OK. Refers to LI in Gl 
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# Error. G3 is not really nested inside Gl . Since G3 

# is global, it is really declared at an outermost level, 

# and so G1.G3 is meaningless. 
PListG2.G3.L3; 

} . 



LocalPList L3 
{ 

10 #OK. Refers to G2.L2. The enclosing global scope is G2 

# and the name L2 is declared in G2. 
PList L2; 

} 

} 



15 All pattern list file names and pattern file names are required to be unique across 

the test plan using them. 

A pattern list reference can refer to a pattern list defined either before or after the 
reference in the same file. 

Recursive and mutually recursive pattern list definitions are not permitted. 
20 While there is nothing in the pattern list file syntax to prevent the user from creating such 

definitions, the parser will flag an error when it detects such conditions. Note that there is some 
cost associated with the detection of such conditions. The user will be able to switch off the 
check if s/he can assume the responsibility of guaranteeing that the input space is free from 
mutually recursive definitions. 

25 GlobalPList Gl 

{ 

LocalPList L2 
{ 

LocalPList L3 
30 { 

#Eiror. L2 runs L3 which runs L2. 
# This is a recursive reference to L2 
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PList L2; 
PList G2; 

} 

} 

} 

* 

GlobalPList G2 
{ 

# Error. Gl 12 runs L3 which runs G2 which runs Gl X2. 

# This is a mutually recursive reference to Gl 12. 
PList G1.L2; 

} 

The syntactic description of patterns and pattern lists allows for options to be 
specified on them. In general options are vendor specific. The syntax allows for any pattern or 
pattern list to have a number of options specified, each with a number of parameters. In we 
describe some supported options that will be recognized by most vendors. 

The dynamic (i.e., execution) semantics of pattern trees is described in after 
defining a pattern execution sequence. 

E2. Patterns 

Figure 6 illustrates a pattern compiler 602 and a pattern loader 604 according to 
an embodiment of the present invention. The user-defined contents of a pattern are available in 
a pattern source file 606, which is a plain text file. A pattern compiler will be responsible for 
compiling a source file into a module-specific format suitable for loading on the tester 
hardware; this latter file will be referred to as the pattern object file. The following are the 
general attributes: 

1 . A Pattern object is not creatable by the user; rather, the user always deals with 
pattern lists, which are collections of other pattern lists and/or patterns. A 
pattern list object creates, owns and maintains the pattern objects contained 
within it, while making them accessible to the user if necessaiy. 

2. A pattern is uniquely named within a test plan, i.e., no two patterns within the 
test plan can have the same name. The name of a pattern is distinct from the 
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name of the file containing it The pattern file name is the one used in the 
pattern list file to refer to a pattern, while the actual name of the pattern is 
defined in the pattern file. 

In an embodiment of the invention, in general, a single DUT (device-under-test) 
might be connected to tester modules from different vendors. This has implications for the 
entire pattern compile-load-execute chain. The main ones are described in this section. 

E3. Pattern Compilation 

A pattern compiler 602 thus needs to target a specific site configuration (in terms 
of the vendor-specific digital modules used). For the rest of this discussion, the term Module" 
will be used to refer to a digital module, as an example. In order to allow the integration of 
modules 608 from different vendors into the system, the following procedures are preferred: 

1 . Each module vendor will be responsible for providing its own module-specific 
pattern compiler 610, in the form of a dynamically loadable library or separate 
executable. This compiler library/executable will provide, at the very least, a 
well-known compileQ function that takes as arguments 

* 

a. an array of (one or more) pattern source file pathnames, 

b. the Pin Description file name, 

c. the Socket file name, 

d. an optional directory pathname specifying the destination of the 
compiled object, 

e. an optional array of string name/value pairs that allow the specification 
of any vendor-specific parameters (that can be ignored by other 
vendors). 

2. The pattern source file will accommodate two different types of sections: 

a. a "common" section that will contain information accessible to (but not 
necessarily used by) all compilers, and 

b, one or more optional vendor-specific sections, each identified by 
unique vendor codes, for information usable by specific vendors' 
compilers. 
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3 . A vendor's compiler will not directly create a pattern object file. Instead, the 
tester will provide for a pattern object "metafile" 612, managed by an Object 
File Manager (OFM) 614, which is part of the pattern compiler. The pattern 
compiler may be located on the computer acting as the system controller, or 
offline, e.g., on a network to which the system controller is connected. The 
"pattern object file" referred to so far in abstract terms is actually this object 
metafile. The object metafile will be named the same as the pattern source file, 
with the source file extension replaced by the object file extension. The OFM 
will provide an application programming interface (APIs) to read and write this 
file. The object metafile will have provisions for storing 

a. common header information, 

b. module-specific header information, including information identifying 
the corresponding module and the location of pattern data for the 
module, 

c. module-specific pattern data, organized as required by the module 
vendor, and capable of being interpreted by the module vendor. 

The OFM APIs will allow a module vendor's compiler to write module-specific 
header information and data into the object metafile. Note that this layout of the object metafile 
allows the pattern data to be organized on a per-module basis, even in the case where two or 
more modules in the targeted site are identical. 

Note that additional vendor-supplied configuration information might be needed 
by pattern compilers to facilitate the generation of module-specific hardware loading 
information that can take advantage of efficient data communications such as direct memory 
access (DMA). 

E4. Pattern Load for a Module 

Each module vendor will be responsible for providing its own pattern loading 
mechanism 615, following the general procedure. The pattern object metafile 612 of a module 
608 stores module-specific data in different sections 616. The vendor implementation will use 
the OFM APIs for accessing the relevant module-specific sections from the pattern object 
metafile. The tester framework will be responsible for calling each module's load method in 
turn to load module-specific data to a module from the appropriate section of the metafile. 
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E5. Pattern Files 

It is possible to have each compiler vendor specify entirely different plain text 
formats for patterns, which, in fact, might indeed be necessary in most cases. However, in 
general, for a cycle-based testing environment, where coherent and identical semantics across 
5 modules are necessary for every vector, a shared, generalized syntax for the pattern file is not 
only desirable, but may be necessary. This shared syntax is what will be specified for the 
"common" section in the pattern source file, hi fact, for the majority of cases, it is envisioned 
that the "common" section is the only section (besides header information) that will be required 
in the pattern file, and every vendor's compiler will work with only that section. This section 
1 0 presents rules for the pattern file that all compilers should be able to interpret. The pattern file 
will be organized as follows: 

A 

filejcontents 

version Jnfo pattern ^definitions 

versionjnfo 

15 Version version-identifier ';' 

patternjiefinitions 

pattern ^definition 

patternjiefinitions pattern definition 
20 patternjlefinition 

mainjieader '{' mainjsection '} ' 

mainjieader '{' mainjsection vendorjsectiofis '} ' 

subrjieader '{' subr_section '}' 

subrjieader '{' subrjsection vendorjsections '} ' 

25 mainjieader 

MainPattern identifier 

mainjsection 

CommonSection commonjcontents 
main_section_domains '}' 
30 commonjcontents 

timing^reference timing jnapjreference 

timingj-eference 

Tixrdngfile-name ';' 
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timing jnapjreference : 

TimingMap file-name ';' 

mainjsectionjlomains : 

mainjsectionjdomainsmainjsectionjiomain 

5 mainjsectionjdomain 

mainjsectionjdomain : 

Domain domainjxame '{' main_sectionjcontents '} ' 

■ 

domainjiame 

identifier 

1 0 main_section_contents : 

7nain_sectionjcontentsmainjsectionjcontent 

main_sectionjcontent 
main^sectionjcontent : 

label^spec main jpatternjspec 
15 main jattern^spec 



label_spec 



label':' 



label 



identifier 

20 main _pattern_spec 

mainjoperation capturejnask Jlag 
vectors jzndjwaveforms '}' 
mainjoperation : /* empty V 

common ^operation 
25 jalj)p 

jsrj>p 

jsrcjzp 

jsc_pp 

exitjop 

30 common ^operation 

idxij)p 
idxinjop 
jecjop 
jechjop 
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JffiPP 

jnij)p 
ldin_pp 

5 nopjop 

pause j>p 
sndcj)p 
sndtjop 
stfijop 

10 stijop 

stpsjop 
waitjop 

/* 

* Instructions specific to the MAIN Patterns 
15 V 



jsrjop 



jsrcjop 



20 J SC J>P 



jaljop 



JSR identifier . 



JSRC identifier 



JSC identifier 



JAL identifier 



exitjop 

25 EXIT 

/* 

* Imtructions common to both MAIN and SUBR Patterns 

*/ 

idxijop 

30 IDXI 24-bit number 

idxinjop 



IDXIn index-register 



jecj>p 



JEC identifier 
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10 



15 



20 



25 



30 



jechjop 



JffiQP 



JfflJV 



jmj>p 



ldin_op 



nopjop 



pausejop 



sndcjDp 



sndt_op 



stfijop 



stij>p 



stpsjop 



waitjop 



JECH identifier 



JFF identifier 



JFF1 identifier 



JNI identifier 



LDIN index-register 



NOP 



PAUSE 



SNDC 8-bit number 



SNDT S-6z7 number 



STFI 24-bit number 



STL 24-bit number 



STPS 



WATT 



capturejnask Jlag : /* e/wpfy */ 

capture jnask Jlag CTV 
capturejnask Jlag MTV 
capturejnask Jlag MATCH 



vectors jzndjvaveforms : /* empty */ 

vectors jxndjvaveforms vector 
vectors jmdjvaveforms waveform 
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vector 

vector ^declaration '{' vector Jlata '} 1 

vector ^declaration 

Vector 



vector data 



vector jdatum 

vector data vector datum 



vector datum 



waveform 



pinjiame '= ' vector-value '; ' 
pinjiame identifier ';' 

waveform ^declaration '{' wavefonnjdata '} ' 



waveformjdeclaration 

Waveform 
W 

wavefonnjdata 

wavefonnjdatum 
waveformjdata waveform Jiatum 

waveformjdatum 

waveform-table-pin-group-name '=' identifier ';' 

pinjiame 

identifier 

vendor ^sections 

vendorjsections vendor jection {} 
vendor jsection {} 

vendor ^section 

VendorSection '{' vendor jsection jcontents '}' 

* 

subrjieader 

SubrPattern 

subrjsection 

CommonSection '{' common ^contents 
source selection table subr section domains '}' 
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CommonSection '{' common _contents. 
subr sectionjiomains '}' 
subr_section_domains : 

subr_sectionjdomains subr^sectionjlomain 
5 subrjsectionjiomain 

subrjsectionjdomain : 

Domain domainjiame '{' subr_section_conterits '}' 
sourcejselectionjable : 

SourceSelectionTable '{' source _selector_definitions '}' 
1 0 source_selectorjlefinitions: 

sourcejselectorjdefinitions source ^selector Jiefinition 
sourcejselectorjdefinition 

source jselectorjdefinition: 
15 Sour ceSelector source _selectorjiame '{' 

source jnappings '}' 
source ^selector jiame : 

identifier 

sourcejnappings 

20 source jnappings source ^mapping 

source ^mapping 

source jnapping 

■ 

pinjiame '=' source ';' 

source 

25 MAIN 

BWERT^MAIN 
SUBR 

INVERTJSUBR 

subr_section_contents : 
30 subrjsectionjcontents subr_section_content 

subr section content 
subrjsectionjcontent : 

label \jpec subr jpatternjpec 
subr jpattemjspec 
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subr _patternjspec 

subrj>peration capture jnask Jlag '{' 

vectors jznd^waveforms '}' 
subrjoperation : /* empty */ 

common operation 

rtnjop 

stssjop 

/* 

* Instructions specific to the SUBR Patterns 
V 

rtnjop 

RTN 

stssjop 

STSS identifier 

The following are the descriptions of undefined non-terminals used above: 

1 . version-identifier : A sequence of one or more characters from the set [0-9.], 
where the first character must be a digit. 

2. identifier : A sequence of one or more characters from the set [a-2A-ZJ)-9], 
where the first character must be from the set [a-zA-ZJ. 

3. vendor-section-contents : Arbitrary text that is meaningful only to a vendor- 
specific compiler. 

4. file-name :A valid Windows file name (must be enclosed in double quotes if 
any white-spaces are contained in the file name). Note that this should be a 
simple file name, i.e., it should not have a directory component. 

5. waveform-table-pin-group-name : A sequence of one or more characters from 
the set [a-zA-ZJ)-9], where the first character must be from the set [a-zA-ZJ. 
This variable is declared elsewhere and holds the name of the waveform-table 
that is common to a group of pins. 

6. 24-bit number : A valid decimal number up to a maximum of 1 67772 1 5 . 

7. 8-bit number :A valid decimal number up to a maximum of 256. 
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* 

8. index-register :A valid decimal number. In one embodiment of a module this 
can have a value [1-8]. 

9. vector: This is similar to the Vector statement in STCL. Note that this refers to 
signal names and signal groups names, making it necessary for the compiler to 
have access to the Pin Description file. 

10. waveform-time-reference : A sequence of one or more characters from the set 
[a-zA-Z_0-9], where the first character must be from the set [a-zA-ZJ. 

Pattern files will support comments, which are meant to be ignored by a pattern 
file compiler. Comments will start with the character, and extend to the end of the line. 

The following points should be noted with reference to the constructs in the 
pattern file's header and "common" sections: 

1 . The pattern-name item specifies the name that will be associated with the 
Pattern object that the pattern file contains the data for. This gets carried over 
to the header in the corresponding pattern object metafile. 

2. The waveform-time-reference is the name for a particular waveform-and-timing 
definition that would be defined externally to the pattern file, in the Timing file. 
The specification of a waveform-time-reference in the pattern file would bind 
that particular name (for a waveform-and-timing) to all subsequent vectors, 
until another wavefonn-time-reference were encountered. 

' 3. The operand for a subroutine call (e.g., JSR and JSRC) is a string that should 
either be a pattern-spec label previously encountered in the same pattern file, or 
a pattern-spec label in an externally defined subroutine pattern. This operand 
will ultimately be resolved for the purposes of loading/handling subroutines. 
The labels for subroutine call operands are required to be unique across the 
system. 

Note that while waveform-time-reference names could be anything that is 
syntactically correct, due to specific hardware implications the waveform-time-reference names 
may need to be restricted to a previously known, well-defined set (which, for added readability, 
can be optionally mapped by the user to user-chosen names, the mapping presented in an 
optional file). 
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Also note that the pattern and waveform-time-reference source files should 
provide initial configuration data for all DUT channels which have connections to physical 
tester channels. If subsequent data is omitted for any DUT channel, the pattern compiler will 

■ 

"pad" the pattern data to hold output from the initial level. 
5 Pattern File Example 

A simple example of a MAIN Pattern source file will help illustrate the usage. 

# Filename : goodl.pat 
# 

10 Version 1.0 ; 

# 

# Main Pattern definition: 

MainPattern goodl 
15 { 

CommonSection 
{ 

MacroDef defaultDataVal (XXXXXXXX) 
MacroDef noplnstr (NOP) 
20 MacroDef label 1 (Label 1 : ) 

MacroDef jnilnst (JNT) 



# 

# Timing Specifications 
25 # 



Timing "productionTiming.tim"; 

TimingMap n producticniTimingOpenSTARMap.tmap n ; 



30 # Default Domain Cycles 

# 



Domain default 
{ 
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# 

#label: instruction {Vector/Waveform Data} 

# 

NOP { V { DATA = SdefaultDataVal; CLK = 1 ;} W 

{ DATA = wfsl; CLK = wfsl; } } 

JAL myAPG { V { DATA - 00000000; } } 
JSC mySCAN { V { DATA = 10101010; } } 
JSRC mySubroutine {V {DATA = 01010101; } } 
JSR myAPG { V { DATA = 001 1001 1; } } 
STI 100 { } 
labZero: NOP { V { DATA = 0000001 1; } } 

JNI labZero { V {DATA= 11111100; } } 
IDXI 3000 {V {DATA = 10101010; } } 
IDXIn 3 {V {DATA = 01010101; } } 

Slabell NOP { V { DATA - SdefaultDataVal; } } 

IDXI 2000 { V { DATA = 10101010; } } 
NOP {} 

EXIT { V { DATA = LLHHLLHH; } } 

* 

} 

} 

} 

Another example illustrating a SUBROUTINE pattern source file is illustrated 

below. 

# 

# Subroutine Pattern mySubrPatl definition: 



SubrPattern mySubrPatl 



CommonSection 

{ 

# 

# Timing Specifications 
# 
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Timing "productionTixnmg.tim n ; 

TimingMap "productionTimingOpenSTARMap.tmap"; 



# Source Selection Specifications 
# i 



SourceSelectionTable 
{ 

SourceSelector SrcSelDef 
10 { 

DATA=SUBR; CLK=SUBR; DATA=SUBR; 

} 

SourceSelector SrcSelOne 

{ 

15 DATA=MAIN; CLK=MAIN; 

} 

} 



#• 



20 # Default Domain Cycles 

# 



Domain default 
{ 

# 



25 #label : instruction { Vector and Waveform Data setups } 

# 

STI 1 00 { Vector { DATA = 00000000; } } 
IDXI 3000 { Vector { DATA = 00001 111;}} 
IDXIn 3 { Vector { DATA = 0011001 1; } } 
30 Slabell NOP { Vector { DATA = LLHHLLHH; } } 

NOP { Vector { DATA = LLXXXXXX; } } 
NOP { Vector { DATA = LLHHXXXX; } } 
JN1 Labell { Vector { DATA = LLHHLLHH; } } 
STSS SrcSelOne { Vector { DATA = LHLHLHLH; } } 
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RTN { Vector { DATA = LLXXXXXX; } } 

} 

} 

} 

Summary information from the main header and common section in the pattern 
source file is stored in the main header in the object metafile. The summary consists of 
information that is typically required for quick extraction to aid pre-load resolution of addresses, 
etc., or to aid in datalogging. Since the semantics of the common section are exactly the same 
for all compilers, every compiler will be capable of providing the same summary information, 
and the first compiler writing the metafile will store this information. The following is the 
information that will be stored: 

1 . The pattern source file name. 

2. The type of the pattern as declared in the source file. 

3. The version information from the source file. 

> 

4. A list of all the wavefonn-and-timing names used in the pattern source file's 
common section. 

5. A map of all subroutine references to (relative) vector addresses in the pattern 
source file's common section. 

6. A map of all label references to (relative) vector addresses in the pattern source 
file's common section. 

7. General bookkeeping information: vector count, instruction count, etc. 

The open architecture test system requires both pattern and pattern list files to 
have explicit, and different, extensions. For pattern files, this applies to both plain text source 

* 

and compiled object files. This is viewed as a convenience to the user to quickly identify the 
file type visually in a directory listing, etc., as well as allow associations to be made on the basis 
of extensions. The pattern list file parser will expect filenames with these extensions: 

Plain text pattern source file: .pat 



Compiled pattern obj ect metafile: .pobj 
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Pattern list file: .plst 

The user can override these default values, e.g., through tester environment 
variables or setup options. 

The tester will require the definition of the following "environment" variables 
5 for file search paths in at least one of the environment configuration files described in: 

TesterJPATLISTJPATH: For pattern list files. 

Tester JPATSRCJPATH: For pattern source files (optional). 

TesterPATOBJJPATH: For pattern object metafiles. 

Note that if the optional environment/setup variable Tester JPATSRCJPATH is 
10 not defined, it will be assumed to be the same as TesterJPATOBJJPATH. In general, it would 
be more efficient to not define Tester_PATSRCJPATH rather than define it with the same value 
as TesterJPATOBJJPATH. 

£6. Software Representation 

A Pattern object is not created by the user; rather, the user always deals with 
15 Pattern List objects, which are collections of other pattern lists and/or patterns. A Pattern List 
object creates, owns and maintains the pattern objects contained within it, while making them 
accessible to the user. A pattern list object in the user's test program is associated with a pattern 
list file on disk, which contains the actual definition of the pattern list. The definition of a 
pattern list provides an explicit name for the pattern list, and identifies an ordered list of 
20 patterns and/or other pattern lists through file name associations. This section describes the 

software representation of pattern lists and patterns, as a prelude to understanding how they are 
manipulated in the tester framework. 

Pattern List Associations 

A single test site in the test system (and, by extension, the test plans in it) can be 
25 associated with multiple top-level pattern lists. However, there is only a single execution 
context for test plans at any given time. Since a top-level pattern list defines an execution 
sequence for the patterns referred to (hierarchically) by it, the active execution context is the one 
corresponding to the currently selected top-level pattern list. Note that this does not imply that 
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only the patterns contained in a single pattern list can be loaded on the hardware at one tune; 
rather, the set of patterns that are required to be loaded on the hardware to make an execution 
sequence viable must always be a subset of all the currently loaded patterns. 

Pattern Trees 



Intuitively, it is felt that a way to represent a top-level pattern list is by some sort 
of a tree data structure. Figure 7 illustrates an embodiment of an ordered pattern tree of the 
invention, assuming that the pattern list A is the top-level pattern list 

Pattern Tree Information Content 



The following information will be stored at every node of the pattern tree: 

1 . The name of the entity (pattern-list or pattern) associated with that node. 

2. The type of the definition source. For a leaf (pattern node), this will always be 
a pattern file; for an intermediate (pattern list) node, this could be either "top- 
level file" (for top-level pattern list definitions) or "embedded in file" (for 
nested pattern-list definitions). 

3. The last modification timestamp of the file on disk the node is associated with. 



list) nodes: 



The following additional information will be stored only in intermediate (pattern 



1 . Execution options (if any) set on the pattern-list object represented by that node 
— i.e., its object options. 

2. The execution options (if any), set on each child reference inside the pattern list 
definition represented by that node — i.e., the reference options, for each of its 
children. 

Thus, the collection of nodes encountered on the unique path from the root to an 
intermediate node, and the sequence in which they are encountered, contain all the information 
necessary to determine the combined, effective, execution options represented by that node . 
The execution options of a pattern are determined by the effective execution options of its 
immediate parent, combined with the reference options its immediate parent might have for it. 
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It should be noted here that while the pattern list parser is in the process of 
creating the pattern tree, certain execution options might require initial storage of values simply 
as strings, since the context of their use might not be resolved until later. An example of such 
an option is a "mask" option, which specifies pin mask information: pattern lists are not 
associated with Socket information, and hence, pin mask options (pin and group names) are 
stored as strings, to be resolved prior to loading. 

The following additional information will be stored only in leaf (pattern) nodes: 

1 . All (possibly transitive) references to subroutines called by that pattern, both 
external and internal, organized as an execution tree. 

Of course, all pattern nodes will additionally have access to — and might choose 
to cache — all the pattern file summary information available in the object metafile common 
header. 

Handling Pattern List Modifications 

Changes made to the contents of a pattern list conceptually affect all references 
to that pattern list. The following rules, which apply as appropriate to pattern objects as well as 
pattern list objects, will be used to manage such changes: 

1 . A change made to the contents of a pattern list file on disk will be propagated 
through the test system only on a loadO command being executed on that 
pattern list (or on any other pattern list that references that one). In other words, 
the pattern list hierarchy in software will always reflect the one currently loaded 
on the hardware. 

2. The user will be able to set a mode that will defeat the checks made during load 
time to synchronize pattern lists with their disk file sources; this will allow 
quicker/safer operation in production mode. 

* 

Pattern Tree Navigation 

The top-level pattern lists associated with a test site (and, by extension, with a 
test plan for that site) have public (global) scope. The system provides APIs to navigate the 
pattern tree representing a top-level pattern list so that users can get access to individual nodes ' 
and sub-trees. 



WO 2004/072670 



PCT/JP2004/001649 



179 

£7. Pattern List Dynamics 

Earlier the static rules of Pattern Lists were described. A description of the 
dynamic (execution) rules of pattern lists is now presented. 

The pattern tree is essential for general pattern management. For example, the 
starting point for a pattern load sequence is a call to the loadQ method on the pattern tree 
currently associated with the site or test plan. However, a pattern tree does not operate in 
isolation. A folly initialized pattern tree will be used to create the following two framework 
objects: 

1 . A top-level pattern list defines a Pattern Execution Sequence for the 
patterns. It describes how such an execution sequence can be derived from the pattern tree 
corresponding to that top-level pattern list. For example, the pattern execution sequence 
corresponding to the pattern tree A shown in Figure 7 is {q, s, t, q, r, q, u, u, v}. The Pattern 
Execution Sequence is conceptually an ordered list reflecting the execution sequence described 
through the pattern tree. The framework establishes and maintains any necessary navigation 
links between pattern tree nodes and corresponding entries in the Pattern Execution Sequence. 

2. The Pattern Set, which is simply a list of all the unique patterns 
(including subroutines) in the pattern tree. This is thus the list that will be used to determine the 
individual patterns that should be loaded on the hardware. The framework establishes and 
maintains any necessary navigation links between pattern tree nodes and corresponding entries 
in the Pattern Set. The Pattern Set for the pattern tree of Figure 7 is (q, s, t, r, u, v) (it is 
assumed that none of the patterns in pattern list A contain any subroutine calls): 

Note that both the Pattern Execution Sequence and the Pattern Set can always be 
derived from the pattern tree; however, it would often make sense to cache them, after initial 
construction, for as long was viable. 

Pattern List Execution Options 

As shown above, each pattern list declaration (preceding its definition) or pattern 
list/pattern reference entry can be followed by a number of execution options. Pattern list 
execution options modify the runtime execution of pattern lists. To allow future extensions, the 
names (and optional values) for these options will be treated simply as strings by the pattern list 
file parser of the pattern compiler, to be interpreted by a particular version as appropriate. 
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Tester prescribes a set of options and their interpretations, described below. However, vendors 
can extend the set of options. In order to allow a parse-time validation of option syntax, the 
pattern list file parser could read an information file for a particular version. Such an 
information file could also be used to specify whether a particular version at all supports the 
specification of execution options. 

For versions that support a set of execution options, the following general rules 
will govern their use. In order to understand these rules, it is useful to visualize the hierarchical 
collection of pattern lists/patterns as an ordered tree. 

1 . Intrinsic options set on pattern list definitions (i.e., in the "local-pattern-list- 
declaration, global-pattern-list-declaration" productions in the file are, in 
effect, direct option settings on the corresponding Pattern List object in the 
user's test program. They thus apply to all references to that pattern list object, 
and are referred to as object options. 

2. Referential options set on references to pattern lists/patterns (i.e., in the 
"pattern-entry" and "pattern-list-entry" productions in the file limits the scope 
of the options to a specific path in the hierarchy — the path (established by the 
declaration order of pattern lists/patterns) that leads from the root of the tree to 
the reference under consideration. These are thus options on specific object 
references (and not on the objects themselves), and are referred to as reference 
options. 

3. The effective option settings for any list/pattern in the collection hierarchy 
(established by the declaration order of pattern lists/patterns) are a combination 
of the object and reference options encountered along the path from the root of 
the tree to that list/pattern. The specific combination mechanism (e.g., set 
union, set intersection, or any other conflict resolution algorithm) is a property 
of the option itself. 

Note that a consequence of the above rules — and the fact that there is no facility 
to set execution options on a pattern definition in a pattern file — is that there is no direct rule to 
set options which apply to all references to a pattern. The mechanism for achieving this is to 
use a single-pattern pattern list. 

The tester specifies a certain set of pattern list execution options that modify its 
burst behavior, and that modify its execution sequence. 
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When an execution sequence for a pattern list is submitted to the hardware, the 
hardware produces a burst. A Burst is the execution of a sequence of patterns directly by the 
hardware, without any involvement from the software. A Burst Discontinuity is a position in an 
execution sequence where a prior burst is terminated, and a new burst is started. 

One of the objectives of the pattern management software is to provide the 
hardware with the execution sequences that it needs to produce a burst on. By default, a pattern 
tree yields an execution sequence, which if submitted to the hardware will result in a single 

burst. This behavior can however be modified by the use of options on the pattern list. Thus, 
the use of options result can result in burst discontinuities. - 

Furthermore, users will sometimes require a prologue or epilogue pattern to be 
run before or after every pattern or every burst. This modifies the execution sequence to be 
submitted to the hardware. 

During the creation or modification of the Pattern Execution Sequence object, the 
framework has all the information necessary to determine, and report if required, breaks in 
pattern bursts resulting from the combination of execution options specified and the particular 
execution sequence embodied by the pattern tree. While doing this, it might need to investigate 
the hardware capabilities of the modules in the system. For example, one hardware 
implementation allows four stored configurations for pin masks, of which two (0 and 3) are 
used for default masked (to support Mask Tliis Vector, MTV) and unmasked operation. The 
user is thus allowed two different global pin-mask configurations without breaking burst mode. 

Note that if a module vendor does not support pattern list implementations in 
hardware, the vendor's processing of the Pattern Execution Sequence would result in individual 
execution of all patterns in the execution sequence. In both Site-Compatible and Site- 
Heterogeneous systems, the burst capability of sites would be limited by the "lowest common 
denominator". The tester provides for a certain default set of options and their parameters is 
described below. Each option is specified by stating: 

Whether it is Intrinsic (i.e. associated with a definition with the Global or Local 
keyword) or Referential (i.e. associated with a reference with the Pat or PList keyword). 
Intrinsic options apply at the point of definition and at every reference, but referential 
options apply only at the reference they are associated with. 
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Furthermore, an option is said to be Inherited by Children if the option is assumed to apply 
recursively to all statically (syntactically) or dynamically (semantically by being referenced) 
nested patterns or pattern lists. 

Below is the list of options. Every compliant vendor will interpret these options 

as specified. 

1 . Mask <pin / pin group> 

Intrinsic when applied to GlobalPList, LocalPList 
Referential when applied to PList, Pat. 
Inherited by children. 

This pattern list will always have the compare circuits of the pins referred to by 
the indicated pin or pin group disabled. Sometimes, hardware limitations may 
result in burst discontinuities. 

2. BurstOff 

Intrinsic when applied to GlobalPList, LocalPList 
Referential when applied to PList, Pat. 
Not inherited by children. 

This pattern list will always execute in the non-burst mode. This option is not 
inherited by children, but the BurstOffDeep option (below) is inherited by 
children. 

3. BurstOffDeep 

Intrinsic when applied to GlobalPList, LocalPList 
Referential when applied to PList, Pat. 
Inherited by children. 

This pattern list will always execute in the non-burst mode. This option is 
inherited by children, but the BurstOff option (above) is not inherited by 
children. Note that the BurstOfiDeep option cannot be turned off by a child. 

4. PreBurst <pattern> 

Intrinsic when applied to GlobalPList, LocalPList 

Inherited only by child nodes having no burst options specified. 

The indicated pattern is to be prefixed to all bursts within this pattern list. The 

PreBurst pattern occurs just before every burst that is started due to this pattern 

list node. The option is not applied when already within a burst which has a 

PreBurst option that is the same pattern. 
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5. PostBurst <pattern> 

Intrinsic when applied to GlobalPList, LocalPList 
Inherited only by child nodes having no burst options specified. 
The indicated pattern is to be suffixed to all bursts within this pattern list. The 
5 PostBurst pattern occurs just after every burst that is started due to this pattern 

list node. The option is not applied when already within a burst which has a 
PostBurst option that is the same pattern. 

6. PrePattem <pattern> 

Intrinsic when applied to GlobalPList, LocalPList 
1 0 Not inherited by children. 

The indicated pattern is to prefixed to all patterns within this pattern list. 

7. PostPattern <pattern> 

Intrinsic when applied to GlobalPList, LocalPList 
Not inherited by children. 
1 5 The indicated pattern is to be suffixed to all patterns within this pattern list. 

■ 

8. Alpg<alpg object name> 

Intrinsic when applied to GlobalPList, LocalPList 
Not inherited by children. 

The named ALPG object stores relevant information such as slow speed APG 
20 register settings, read latency, immediate data registers, address scramble, data 

inversion, data generators, etc. 

9. StartPattern <pattern> 

Intrinsic when applied to GlobalPList, LocalPList 
Not inherited by children. 

25 The pattern list will start executing at the first occurrence of the StartPattern in 

its execution sequence. 

10. StopPattern <pattern> 

Intrinsic when applied to GlobalPList, LocalPList 
Not inherited by children. 

30 The pattern list will stop executing at the first occurrence of the StopPattern in 

its execution sequence. 

* 

1 1 . StartAddr <vector offset or label> 

Intrinsic when applied to GlobalPList, LocalPList 
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Not inherited by children. 

This must be accompanied by a StartPattern option. The pattern list will start 
executing at the StartAddr in the first occurrence of the StartPattern in its 
execution sequence. 

5 12. StopAddr <vector offset or label> 

Intrinsic when applied to GlobalPList, LocalPList 
Not inherited by children. 

This must be accompanied by a StopPattern option. The pattern list will stop 
executing at the StopAddr in the first occurrence of the StopPattern in its 
1 0 execution sequence, 

1 3 . EnableCompareJStartPattern <pattern> 
Intrinsic when applied to GlobalPList, LocalPList 
Not inherited by children. 

■ 

Pattern comparison will commence at the first occurrence of the indicated 
15 pattern. 

14. EnableCompareJStartAddr, EnableCompare_StartCycle 
Intrinsic when applied to GlobalPList, LocalPList 

Not inherited by children. 

This must be accompanied with EnabelCompare_StartPattern. Indicates the 
20 address or cycle within the pattern where pattern comparison is to start. 

1 5 . EnableCompare_StopPattern <pattern> 
Intrinsic when applied to GlobalPList, LocalPList 
Not inherited by children. 

Pattern comparison will complete at the first occurrence of the indicated pattern. 

25 16. EnableCompare_StopAddr, EnableCompareJStopCycle 

Intrinsic when applied to GlobalPList, LocalPList 
Not inherited by children. 

This must be accompanied with EnableCompareJStopPattern. Indicates the 
address or cycle within the pattern where pattern comparison is to complete. 

30 17. Skip. 

Referential when applied to PList, Pat. 
Not inherited by children. 

Causes a pattern or the entire subsequence dominated by a pattern list to be 



WO 2004/072670 



185 



PCT/JP2004/001649 



skipped. This will also cause skipping of all options at the root of this pattern 
list sub-tree. It is as if this pattern sub-tree were not there for execution 
purposes. 

Pattern List Burst Control 

As described earlier, when an execution sequence for a pattern list is submitted to 
the hardware, the hardware produces a burst of a sequence of patterns, without any involvement 
from the software. A Burst Discontinuity is a position in an execution sequence where a prior 
burst is terminated, and a new burst is started. The PreBurst , PostBurst, BurstOff and 
BurstOffDeep options control where the burst discontinuities occur, as described in the option 
list above. PreBurst and PostBurst options determine burst discontinuities subject to certain 
additional rules described below: 

1 • When a parent list has PreBurst and PostBurst options, and the nested list has 
the same corresponding options, there is no burst discontinuity, and the 
PreBurst and PostBurst options of the nested list do not apply. There is only a 
single burst applying the PreBurst and the PostBurst of the parent list. 

2. Notice that when the nested list has no burst options, it is equivalent to having 
the same PreBurst and PostBurst options as the parent list by the description of 
these options. Consequently, nested lists with no burst options do not result in a 
burst discontinuity. 

3 . If rule 1 above does not apply and there is a contribution to the pattern 
execution sequence from the start of the parent list to the start of the nested list, 
then there is a burst discontinuity at the start of the nested list. In this case the 
PreBurst and PostBurst of the parent list apply to this contribution to the pattern 
execution sequence from the parent list. The PreBurst and the PostBurst of the 

* 

nested list apply to the nested list. 

* 

4. If rule 1 above does not apply, and there is a contribution to the pattern 
execution sequence from the end of the nested list to the end of the parent list, 
then there is a burst discontinuity at the end of the nested list. In this case the 
PreBurst and PostBurst of the parent list apply to this contribution to the pattern 
execution sequence from the parent list. The PreBurst and the PostBurst of the 
nested list apply to the nested list. 
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5. If rule 1 does not apply, and there is no contribution to the pattern execution 
sequence from the parent list other than from the nested list, then the PreBurst 
and the PostBurst of the parent list do not apply. There is only a single burst 
applying the PreBurst and PostBurst of the nested list. 

Below are a few examples illustrating the effect of options on the execution 
sequence. To simplify, it is assumed that all the pattern lists are specified in a single file. 

Example 1 : Use of BurstOff 

This example illustrates BurstOff and PreBurst. Of particular emphasis is that 
BurstOff causes patterns to run singly in bursts that are one pattern long. Hence the PreBurst 
option still applies. The input pattern lists are as below: 

Global A [BurstOff] [PreBurst pat_z] 
{ 

Pat q; 

PList B; 

Pat r; 

Pat s; 

Global C 

{ 

Pat t; 
PList D; 

}; 

PList D; 
PList E; 

}; 



Global B 
{ 

Pat a; 
Patb; 
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}; 



Global D [BurstOff) 
{ 

Pate; 
Patd; 

}; 



10 



Global E 
{ 

Pat e; 

}; 

1 5 The tree rooted at A may be represented in Figure 8. 

The execution sequence for this pattern is below. The | character indicates a 
burst break. This pattern list executes in 10 bursts, the first one having patterns z and q, and the 
last one with pattern e: 

zq|ab|zr|zs|t|c|d|c|d|e 

20 Note the following about this execution sequence: 

1 . Since the BurstOff option on A is not inherited by B, the patterns a and b in B 
operate as a burst. 

2, Since the PreBurst option on A is not inherited by B, the a and b in the burst by 
B is not prefixed by z. 

25 3 . The prefix by z only happens for the patterns that are executed due to being 

direct children of a, namely patterns q, r and s. These patterns are executed 
singly as if in a burst that is only one pattern long due to A having the BurstOff 
option. The BurstOff requires patterns to be run individually in one-pattern 
long bursts. Hence, the PreBurst and PostBurst options still apply. 
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4. Pattern list D has an intrinsic burst off option that causes its children c and d to 
execute singly. They do not inherit the PreBurst z from A. 

Example 2: Use of BurstOffDeep 

This example illustrates the BurstOffDeep option. BurstOffDeep during pattern 
list definition affects nested definitions and referenced lists. However, PreBurst and PostBurst 
options are not inherited by nested and referenced lists. The example uses the same patterns A, 
B, C, D, E as in example 1, but the options are different: 

5. Options on definition of A: [BurstOffDeep], [PreBurst z], [PostBurst y] 

6. No other options on any other node. 

The execution sequence is as below. As earlier, the | character indicates a burst 

break. 

zqy|a|b|zry|zsy|t|c|d|c|d|e 
Note the following about this execution sequence: 

1 . PreBurst and PostBurst are not inherited by B, C, D, E. 

2. BurstOffDeep is inherited by B, C, D, and E. 

Example 3: PreBurst and PostBurst Inhibition 

Suppose now the pattern list tree of Example 1 is considered, where the options 

are: 

1 . Options on definition of A: [PreBurst x] [PostBurst y] 

2. Options on definition of C: [PreBurst x] [PostBurst z] 

3. No other options on any other node. 

The execution sequence would be: 
xqabr stcdcdey 



The reasons why the "t c d" subsequence is not "x t c d z" are as follows: 
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1 . The first x is inhibited since it is equal to the pre-burst option x that is 
associated with the current burst in effect. 

2. The last z is inhibited since the Postfiurst z is not inherited to D, and there is no 
pattern that is generated from C to which the z can be appended. 

5 Example 4: Use of Skip 

This example illustrates the effect of the Skip option on nested definitions and 
referenced lists. The example uses the same patterns A, B, C, D, E as in example 1, but the 
options are different: 

1. Options on definition of A: [Skip], [PreBurst z], [PostBurst y] 
10 2. Options on reference to r: [Skip] 

3. Options on definition of C: [Skip] 

The execution sequence is a single burst with no breaks as below: 
zqabscdey 



Note the following about this execution sequence: 
15 1 . The nodes for r and C are skipped. 



2. There are no burst breaks at all. 



Example 5 : Use of Mask 

This example illustrates the effect of the Mask option and its effects on pattern 
and pattern list definitions and references. The example uses the same patterns A, B, C, D, E as 
20 in example 1, but the options are different: 

1 . Options on definition of A: [mask pinl_pin2], [PreBurst z] 

2. Options on reference of B: [mask pin3] 

3 . Options on definition of B : [mask pin4] 



Options on reference of e: [mask pin5] 
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5. No other options on any nodes. 

The name "pinl _pin2" specifies a group which masks Pinl and Pin2. The names 
"pin3", "pin4" and ,4 pin5" specify masking Pin3, Pin4and Pin5 respectively. The execution 
sequence is provided below, with | indicating the burst break. The numerals below each pattern 
5 indicate the pins that are masked during that pattern execution. 

zqabzrzstcdcd|e 
11111111111111 
2 222222 222222 2 
3 3 5 
10 4 4 

Note the following about this execution sequence: 

1 . The vendor's hardware can only accommodate 2 mask blocks without a burst 
break. Until e is executed the two mask blocks are pins {1, 2} and pins {1, 2, 3, 
4} . When pattern e arrives with a different mask block of pins { 1, 2, 5}, the 
1 5 hardware requires a burst break. 

Example 6: Use of Inherited Options and References 

This example illustrates that an inherited option at a definition does not apply 
when the definition is referenced. Consider the following example: 

Global A 
20 { 

Global B [BurstOffDeep] 
{ 

Global C 
{ 



25 



}; 



} 



30 



PList C; 
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}; 

Global D 
{ 

PList C; 

}; 

The BurstOffDeep option is inherited by C at its point of definition. However, it 
is not an intrinsic option, and so it is not applied to C at both its point of references. 

Example 7: PreBurst and PostBurst with Nested Lists 

Consider the following example: 

GlobalPList A [PreBurst x] [PostBurst y] 
{ 

Pat pi; 

LocalPList B [PreBurst x] [PostBurst y] 

■ ■ * 

{ 

Patp2; 

} 

LocalPList C 
{ 

Patp3; 

} 

LocalPList D [PreBurst x] [PostBurst z] 
{ 

» 

Pat p4; 

} 

LocalPList E [PreBurst w] [PostBurst y] 
{ 

Pat p5; 

} 
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Patp6; 

} 

The execution sequence is: 
x pi p2 p3 y | x p4 z | w p5 y | x p6 y 

* 

1 . Pattern p2 is in the same burst as p 1 because the PreBurst and PostBurst options 
of the nested list are specified the same as the parent. Pattern p3 is also in the 
same burst because these options are inherited the same as the parent. These 
options have at least one different member in the remaining nested lists, giving 
rise to burst discontinuities 

Timing 

The user interacts with the system primarily by defining the test setups using 
pattern files. The Timing File is used to describe the Timing of these patterns. This file requires 
other system files (e.g. Pin, SpecSelector) for underlying definitions to be resolved. Further the 
Spec-Selectors and Global definitions used to resolve various variables used in the Timing 
definition are encapsulated in a composite TestConditionGroup object. Higher-level files, such 
as the Test Plan file, in turn use this TestConditionGroup instance. 

The Test Plan File contains references to the TestConditionGroup object. The 
Pattern Source File makes references to the WaveformSelector components within a 
TimingMap object. The Timing objects itself references the Pin objects. Optionally the Timing 
object might also reference a variable modulated by a SpecSelector object. These relationships 
are illustrated in Figure 9. 

The Pattern object within the Pattern-List specifies the name of the 
WaveformSelector object to use for a set of pattern characters. Also note that the TimingMap 
file is specified in the pattern. Patterns need not be compiled if this map is not changed. 

Version 1 .0; 
MainPattern 

■ 

{ 

CommonSection 
{ 
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Timing = myGalxy.tim; 
TimingMap = myGalxyMap.tmap; 
» • • 

Domain default 
{ 

NOP V {SIG=1;CLK=1;DATA=L;} W{SIG=wfsl; 

FASTCLK=wfsl; } 
NOP W {SIG=wfs2;} 

NOP V {SIG=L;} 
NOP V {SIG=0;} 

} 

} 

} 



The TestConditionGroup File objects import the Timing object to use and the 
TimingMap object to use. Each Test uses a TimingCondition instance derived from the 
TestConditionGroup object for that instance. Thus multiple Timing objects, which support the 
same set of waveform tables, can be stored in the tester framework and can be swapped as 
required. Similarly multiple Test Plan Files can share a common TestConditionGroup object. 

An example of a Test Plan description file illustrates the usage of the Timing 

object below. 

Import patlistl.plist; 
Import timl .tim; 
Import tim2.tim; 
Import tmapl .tmap; 
TestConditionGroup timl _prod 

{ 

SpecSet = prodTmgSpec(min, max, typ) 
{ 

period = 10ns, 15ns, 12ns; 
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} 

Timings 
{ 

Timing = timl; 
5 TimingMap = tmapl ; 

} 

} 

TestConditionGroup tim2_prod 

{ 

1 0 SpecSet = prodTmgSpec(min, max, typ) 

{ 

period = 10ns, 15ns, 12ns; 

} 

Timings 

15 { 

Timing = tixn2; 

TimingMap = tmapl; 

} 

} 

20 TestCondition timl_prod_typ 

{ 

TestConditionGroup = timl_prod; 
Selector = typ; 

25 TestCondition tim2_prod_max 

{ 

TestConditionGroup = tim2_prod; 
Selector = max; 

} 
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Test FunctionalTest MyFunctionalTestSlow 
{ 

PListParam = patlistl; 
TestConditionParam = timl_prod_typ; 

} 



Test FunctionalTest MyFunctionalTestFast 
{ 

10 PListParam = patListl; 

TestConditionParam = tim2j>rod_max; 

} 



"timl" and "tim2" are two Tests within a Test Plan using different timing objects 
15 defined earlier. The Timing object defines various waveforms on a per pin basis. The pins used 
in the Timing file and the Timing Map file need to be defined appropriately in the Pin definition 
file. 

The Timing object can use SpecificationSet objects to define values within the 

■ 

waveform objects. Though the Timing object can include hard-coded values for various 
20 attributes it is usually the case that users have various attributes be assigned values using 

variables. These variables in turn can depend on SpecificationSet objects. An example of this 
usage is illustrated below. 

Version 1.0; 

Timing basic_functional 
25 { 



PinSIG 
{ 

WaveformTable wfsl 
30 { 

{ 1 { U@t_le ; D@t_te D; Z@45ns;} } 

>; 

}; 
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Pin CLK 
{ 

WaveformTable wfsl 
{ 

{ 0 { U@20ns; D@40ns; }}; 

}; 

} 

The variable U@t_le, which defines the edge placement, is defined elsewhere 
and is dependent on a SpecificationSet. The SpecSelector is defined as illustrated below. 

SpecificationSet prodTmgSpec( min, max, typ) 
{ 

t_le = 10ns, 14ns, 12ns; 
t_te = 30ns, 34ns, 32ns; 

• • • 

} 

The changing of the timing used by changing the spec is illustrated in the 
example below. 

TestCondition prodTmpJyp 
{ 

TestConditionGroup = prodTmgSpec; 
SpecSelector = typ; 

} 

TestConditionGroup prodTmp_max 
{ 

TestConditionGroup = prodTmgSpec; 
SpecSelector = max; 

}; 

F2. Mapping to the Timing Components of a tester 
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The timings "typ" and "max" use the typical/max specification in the 
SpecSelector. Two components of a tester module are directly involved with the generation of 
wave shapes and their associated timings. The two modules are the Pattern Generator (PG) and 
the Frame Processor (FP). A simplified block diagram illustrating the wave shape formatting 
and the timing generation by the Frame Processor within the open architecture test system 
architecture is illustrated in Figure 10. A brief description of the generation of waveforms is 
given below. 

The Pattern Generator 1002 generates a timing set which is common for all the 
pins in the module. This timing set is called the Global Timing Set (GTS). There are three 
modes in which the Pattern Generator can be set up. These three modes affect the number of 
bits that can be used to describe the GTS. In addition these settings also impact the number of 
bits used to select a bank and whether the Capture This Vector (CTV) and Mask This Vector 
(MTV) bits are set or not. To instruct the tester to capture the results of this vector, the user 
uses the CTV flag in the Pattern file. Similarly the user uses the MTV flag in the pattern to 
instruct the tester to mask the results of the current vector. This is illustrated in Table 1 below. 
The Pattern Generator 1002 is also responsible for the generation of Waveform Characters 
(WFC). WFCs are generated on a per pin basis. The tester module uses a fixed number of bits 
to describe the WFCs. 



GTS bits 


GTS in a 
Bank N 


GTS Bank 


CTV 


MTV 


8bits 


256 


4 


NO 


NO 


7bits 


128 


8 


YES 


NO 


6bits 


64 


16 


YES 

* 


YES 



Table 1 



The tester module provides a Frame processor 1004 per pin. Each Frame 
Processor contains a Timing Set Scrambler (TSS) 1006, which has a total depth of up to 1024 in 
this example. The TSS 1006 can be partitioned into a number of banks 1008 depending on the 
mode of the Pattern Generator as described earlier and illustrated in Figure 10 where 16 banks 
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of 64 entries per bank are being used. The TSS is provided so as to allow more flexibility in the 
ability to define Waveform Tables for each pin. In the 'TP" mode the TSS outputs a Timing Set 
using 2 bits. Thus the TSS will generate a total of four distinct physical Timing Sets per pin. 
These Timing Sets are referred to as the Local Timing Sets (LTSs). 

« 

The Frame Processor 1004 combines LTS and WFC and creates an index 1010 
into the Waveform Memory 1012 and Timing Memory 1014. In the "FP" mode the 5-bit value 
is split up with 2 bits being generated by the LTS and 3 bits being generated by the WFC. Thus 
the depth of the physical Waveform Memory and Timing Memory is 32 deep per pin though a 
maximum of 4 physical Timing Sets may be used. The Waveform Memory contains the 
enabled timing edges that form the wave shapes. The timing values for the enabled edges are 
obtained from the Timing Memory, Thus, the Frame Processor formats wave shapes. 

Mapping Methodology 

The methodology is to map all the WavefonnTable blocks on a per pin basis to 
LTSs in the tester. If tester hardware supports 4 LTSs, the user can define a maximum of 4 
WavefonnTable blocks. Each WaveformTable block can have a maximum of n waveform 
definitions for the tester digital module. 

The Timing-Map file provides a mapping of Logical WavefonnSelectors defined 
in the Tuning-Map block to the WavefonnTable for the module in open architecture test system, 
hi this case the tester supports up to 256 Logical WavefonnSelectors. Jn open architecture test 
system system , the Logical WavefonnSelectors map directly to the GTSs. The Pattern 
compiler depends on both the Timing-Map and the Timing blocks to be able to compile the 
pattern files. However if the waveform characters in the WavefonnTables of the Timing block 
are unchanged or the WavefonnSelector mappings in the Timing-Map block are unchanged, 
there is no need to re-compile the pattern. 

Example Using this Mapping Methodology 

To illustrate the mapping into a tester Digital Module the following assumptions 
are made: the Frame Processor is set to the FP mode; and CTV and MTV bits are set so total 
number of GTS bits is 6 and the total number of Timing Bank Selector bits is 4. 

Each WaveformTable defined in the Timing block is mapped to a distinct LTS 
within the Timing file. This is done on a per-pin basis. Thus WaveformTable seql is mapped to 
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LTS1. In the case of the "SIG" pin all 8 possible waveform entries are used up. However the 
"CLK" pin requires a single waveform entry and thus uses up a single row in the Waveform 
memory (WFT) and the Waveform Timing memory (WTM). 

The mapping of the first 2 physical waveforms of the "SIG" pin is illustrated in 
Figure 1 1 . As this WavefomiTable maps two waveform characters that need separate 
configurations of the edges, we end up allocating two entries in the Waveform memory (WFT) 
1 1 12 and the Waveform Timing memory (WTM) 1 1 14. The shape of the waveform is stored in 
the WFM and the timing details are stored in the WTM. One embodiment of the module has a 
total of6 timing edges T1,T2,T3,T4,T5 and T6. These map directly to the Events El, E2, ... 
defined in the waveforms within a Edge Resource section of the Timing block. If more than 6 
events are defined in the Timing block and this is used with a the above module, it will result in 
an error. 

In the example of Figure 1 1, the first waveform character "0" uses Timing Edge 
Tl to program the "Force Down" or "D" event, which occurs- at time 10ns into the cycle. 
Timing Edge T2 is also used to generate a "Force Down" or "D" event at time 30ns. Finally 
Timing Edge T3 is used to generate a "Force Off or "Z" event at time 45ns. 

The second waveform character "1" uses Timing Edge Tl to program the "Force 
Up" or "U" event, which occurs at time 10ns into the cycle. Timing Edge Tl is also used to 
generate a "Force Down" or "D" event at time 30ns. Finally Timing Edge T3 is used to 
generate a "Force Off' or "Z" event at time 45ns. 

In this fashion, the WFCs are mapped into the WFM memory and WTM memory 
of the Frame Processor. The final setup of Waveform Memory WFM of LTS1 for pin "SIG" is 
illustrated in Table 2 below. 
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Index 


(WFC) 


TlSet 


TlReSet 


T2Set 


T2ReSet 


T2Drel 


T2Dret 


EXPH 


EXPHZ 


T3Set 


T3ReSet 


T3Drel 


T3Dret 

• 


T4Drel 


T4Dret 


EXPL 


EXPHZ 


0 


0 




i 

X 




i 
i 












■ 




1 
1 
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1 


1 

» 






i 

JL 






• 










1 
1 










2 


d 




1 


1 


















1 
1 








« 


3 


u 


1 
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7 
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1 





















Table 2 
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The final setup of Waveform Timing Memory WTM of LTS1 for pin "SIG" is 
illustrated in Table 3 below. 



Index 


(WFC) 


H 


H 


EXPH 






EXPL 


0 


0 


10ns 


30ns 




45ns 






1 


1 


10ns 


30ns 




45ns 






2 


d 


12ns 


32ns 




42ns 






3 


• 

u 


12ns 


32ns 




42ns 






4 


L 












17ns 


5 


H 






17ns 








6 


m 












15ns 


7 


n 






15ns 









Table 3 
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The "CLK" pin uses up a single waveform and thus the WFM and WFT for this 
pin are very simple. The final setup of Waveform Memory WFM of LTS1 for the "CLK" pin is 
illustrated in Table 4 below. 



Index 


(WFC) 


TlSet 


TlReSet 


T2Set 


T2ReSet 


T2Drel 
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EXPH 


EXPHZ 


T3Set 


T3ReSet 


T3Drel 


T3Dret 


T4Drel 


T4Dret 


EXPL 


EXPHZ 
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Table 4 

The final setup of Waveform Timing Memory WTM of LTS2 is illustrated in 

Table 5 below. 



Index 


(WFC) 
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3 



4 



5 



6 



7 



Table 5 

» 

The TimingMap block explicitly maps out the WaveformSelectors to the 
Waveform tables of the Tuning block. For a tester system this boils down to setting up the 
Timing Set Scrambler (TSS) memory. The TSS basically contains a mapping from the GTS to 
' 5 the LTS that holds the settings. The TSS setup for our example for pin SIG will look like Table 
6 below. 



GTS 


LTS 


0 (wfsl) 


1 


1 (wfs2) 


1 


2 (wfs3) 


2 


3 (wfs4) 


1 


4 (wfs5) 


3 


5 (wfs6) 


1 


• 




N (wfsl) 


1 
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• 




255 





Table 6 



Finally after the TSS and LTS setup mappings are resolved, the Pattern Compiler 
can use this information to program the pattern with the correct waveform table (LTS) and the 
correct waveform character to use. Thus our example pseudo-pattern considering only pin 
5 "SIG" is illustrated in Figure 1 1 . Note that this compilation has no dependency on the Timing 
block and only depends on the Timing-Map block. 

G. Tester Operation 

This section describes the basic operation of the tester operating system (TOS). 
The activities considered in this section are: 

10 system initialization 
Test Plan loading 
Pattern loading 
Running a Test Plan 
Running an individual Test 

15 

System Initialization 

In order to initialize the system in one embodiment, certain assumptions must be 
satisfied, and certain conditions must be met. The following sub-section lists these. 

Preconditions 

20 Copies of the relevant system software components have a central store, whose 

location is known to the System Controller. This may be on the System Controller itself, or on 
another system with a network mounted directory (or known to the SYSC via another 
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mechanism) — whatever the mechanism, before the system can function, all software must be 
made available to the System Controller for use. This software includes: 

vendor hardware control (i.e., module software) DLLs, 

standard or user test class DLLs, and 

user test plan DLLs. 

+ 

♦ 

The system module configuration file is available on the System Controller. 
Recall that this file allows the user to specify the physical configuration of the tester, e.g., the 
physical location and type of each module in the system chassis, as well as the names of the 
module software DLLs. 

The system configuration file is available on the System Controller. Recall that 
this file contains the list of Site Controllers in the system, as well as a map of Site Controller 
hostnames to Switch Matrix input port addresses. 

Site controllers have a service called the Site Configuration Manager (SCM) 
running. This service is responsible for determining what hardware is installed in each slot, by a 
process termed "hardware discovery". It is also responsible for participating in the system 
initialization process with the System Controller. Note that the Switch Matrix operation 
protocol dictates, in one embodiment, that the SCM on a single Site Controller, with Switch 
Matrix input port connection address 1, should always be used to configure the Switch Matrix 
connections to the modules. Recall that this "special" site is denoted as SETEC-1. 

The System Controller is responsible for providing each Site Controller's SCM 
with its Switch Matrix connection address. 

Each Site controller's SCM is capable of starting a process called the Test Plan 
Server (TPS). The Test Plan Server on each Site Controller is ultimately responsible for 
containing and executing the user's test plan (or test plans, in the case where a single Site 
Controller is running tests on multiple DUTs). 

Initialization Phase I: System Validation 

» 

Once the above assumptions and preconditions have been satisfied, system 

* 

initialization first proceeds with a system validation step as follows: 
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1 . The System Controller reads the system and module configuration files 

• * 

to initialize the user-specified view of the system. 

2. Using the specified system configuration information, the System 
Controller verifies that the specified Site Controllers are alive, 

5 reachable, and ready (i.e., have SCMs running). Any error during this 

verification step will cause a system error to be raised, and initialization 
to be aborted. 

3. The System Controller then instructs the SCM service at SITEC-1 to 
configure the switch matrix to have access to all hardware modules, and 

1 0 requests it to perform hardware discovery. 

4. The SCM service at SITEC-1 polls all available module slots (known 
hardware locations) for {vendor, hardware} tuples and generates a map 
of {vendor, hardware} tuples to slots. At conclusion, this poll has thus 
identified the entire set of {vendor, hardware, slot} bindings that exist 

15 in the complete system. The results of this poll are sent to the System 

Controller. 

5. The System Controller verifies that the results of the above hardware 
discovery step match the user-specified configuration in the module 
configuration file. Any error during this verification step will cause a 

20 system error to be raised, and initialization to be aborted. 

6. The System Controller then loads a default environment (such as search 
paths for module DLLs, pattern lists, patterns, test plan DLLs, test class 
DLLs, etc.) from the environment setup file(s) at well-known 
location(s). 

25 7. The System Controller ensures that all identified module software 

DLLs exist. If one is not available on the System Controller, it is 
retrieved from the central store, if possible; otherwise, a system error is 
raised, and initialization is aborted. 



30 Initialization Phase II: Site Configuration (Optional) 
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Site configuration, or site partitioning, involves the software-level assignment of 
the available system hardware modules to different sites (i.e., to service multiple DUTs). Recall 
that site-partitioning information is provided in a socket file. 

The tester system allows site (re-)partitioning to be performed both as part of a 
5 test plan load (since each test plan is associated with a particular socket), and as an independent 
user-callable step. In the latter case, the user initiates the site partitioning by providing a socket 
file that is used solely to partition the system. This is especially useful during system 
initialization in the case of multi-DUT testing where each site tests a different DUT type. 
However, this step is optional during the initialization stage, and the user can choose not to have 
10 it performed, opting instead to allow a test plan load to partition the system appropriately. 

Whatever the means chosen to effect site partitioning (by an independent call or 
implicitly through a test plan load), the mechanism is the same. This mechanism is described 
below. 

1 . Given the socket, the System Controller first determines whether the 
15 currently existing system partition is compatible with the socket, or 

whether a re-partitioning is necessary. The default partition during 
initialization is one in which all available modules are connected to 
SITEC-1. The remaining steps below are performed only if re- 
partitioning is needed. 

20 2. The System Controller sends a configuration message to each Site 

■ m 

Controller SCM to re-configure itself with the number and identities of 
DUT sites that are enabled for it under the new socket. Note that this is 
a general procedure, and handles the case where the number of DUT 
sites controlled by a Site Controller is one. The new socket information 
25 is also conveyed to the SCMs. 

3. Each SCM stops the running TPS, if any, and starts a new one, 
initializing it with the new socket, and the number and identities of 
DUT sites that are enabled for it under the new socket. 

4. The System Controller determines which sites need what subsets of the 
30 required system modules. While doing this, it also prepares hardware 

slot information for the sites. The net result is, for each site, a list of 



• 
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slots versus module DLLs assigned to that site. This site-specific list 
will be denoted as the Site Module DLL Slot List (SITE-MDSL). 

5 . The System Controller provides the appropriate SITE-MDSL, as well 
as the necessary module DLLs, to each SCM. Each SCM in turn makes 

5 this information available to the newly-started TPS. 

6. The System Controller then requests SITEC-1 to configure the Switch 
Matrix for the proper site-to-slot connections, that is, for site- 
partitioned operation. . 

7. The TPSs on sites 1 through n load the DLLs specified in their SITE- 
10 MDSL. Each of these DLLs has a function named initializeO which 

takes an array of slot numbers. The TPS calls initializeO with the 
appropriate slot lists for that module type. On any malfunctions at this 
point, a system error is raised, and initialization is aborted. The 
initializeO method does the following: 

15 a. Creates concrete classes based on a standard interface 

DCXXModule, For example, a DLL associated with a digital module 
will create a single IP inModule-based object to service each slot it is 
associated with. 

b. Creates concrete classes based on interface EResource, one 
20 for each Resource unit" in the module. Again, for a digital module, 

each BPinModule-based object will create ITesterPin-based objects for 
all piris in the collection of slots occupied by digital modules. 

8. The TPSs on sites 1 through n then call getXXXModuleO on each 
loaded module DLL to retrieve module contents information. 

25 9. Each call to getXXXModuleO returns a < VendorHWType >Modul e 

class object as an IModule pointer (e.g., AdvantestPinModule). 
Each such IModule pointer is cached by the TPS, which makes these 
available to framework/user code. Note that the collection of 
IModules, IResources, etc. are persistent (at least for the lifetime 

30 of the TPS). 
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10. Once the above steps are complete, the TPS starts to listenO on its 
assigned (well-known) port. This signals to the System Controller that 
the TPS is "ready" to begin normal (i.e., site-partitioned) operation. 

Test Plan Load 

This section describes the steps by which a user Test Plan DLL is loaded on a 
Site Controller (for single or multiple DUT testing). 

Once system initialization (and optionally, initial site partitioning) has been 
completed, user test plans can be loaded. The loading of a user test plan on a Site Controller 
proceeds as follows: 

1 . The System Controller first loads the test plan DLL into its own process 
space, querying it for its associated socket file and its DUT type 
identifier. This information is used to identify the site(s) running this 
test plan, and hence, the Site Controller(s) that this test plan would be 
loaded on. 

■ 

2. The System Controller then uses the socket information associated with 
the test plan to initiate the re-partitioning process as outlined above. 

3. The System Controller extracts the list of test class DLLs used by the 
test plan from the test plan DLL, and once the System Controller has 
verified that the TPS is ready to begin normal (i.e., site-partitioned) 
operation, sends the test class DLLs, and, finally, the test Plan DLL 
itself, to the appropriate TPS. 

4. The TPS calls LoadLibraryO to load it into its process space. It calls a 
well-known function on the DLL to create as many TestPlan objects as 
the number of sites (i.e., DUTs) it is servicing. 

5. The TPS initializes the TestPlan object(s) with the necessary tester 
framework objects. During initialization, the TPS loads the appropriate 
DLLs for the test classes used by the TestPlan object(s) into the 
process space, and creates the test class instances. 
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6. The TPS sets up the communications channel to/from the System 
Controller to the TestPlan objects). 

7. The System Controller communicates with the TPS, and builds its 
proxies for the TestPlan object(s). 



The concludes the successful load of the user's Test Plan on a Site Controller. 
Running a Test Plan 

The method to execute all tests in a test plan according to the pre-definedyZow 
logic is as follows: 

10 1 . The user's application transmits a RunTestPlan message to the TPS. 

The TPS sends an ExecutingTestPlan message to all connected 
applications. The TPS then calls execute^ on the Test Plan. 

2. Testing multiple DUTs with a single Site Controller is performed using 
multiple threads on that Site Controller, one per DUT. Each thread 

15 runs a different, independent instance of the same TestPlan object. 

Since, in this case, module control software DLLs might be shared 
across DUTs, the module commands for hardware communication are 
required to take a DUT identifier parameter. 

3. The TestPlan object iterates over each test in its collection 

20 (alternatively, tells its Flow object to process each test according to the 

flow logic), calling preExecQ, executed), and postExecQ. 

4. As each test executes, status messages are sent back to all connected 
applications. 

Executing a Single Test 

25 A user may wish to execute a single test in a test plan instead of all tests. For 

single test execution, the method is as follows. 



User application transmits a RunTest message to the TPS; the TPS 
sends an ExecutingTest message to all connected applications. The 
TPS then calls executeTestQ on the Test Plan, specifying the test to run. 
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2. The Test Plan object executes the specified test by calling preExecO, 
executeO, and postExecO on that test object. 

3. When the test executes, it sends status messages back to all connected 
applications. 



Although the invention has been described in conjunction with particular 
embodiments, it will be appreciated that various modifications and alterations may be made by 
those skilled in the art without departing from the spirit and scope of the invention. The 
invention is not to be limited by the foregoing illustrative details, but rather interpreted 
according to the scope of the claims. 
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CLAIMS 

What is claimed is: 

1 . A method for developing a test program in general purpose C/C++ constructs, the test 
program for testing a semiconductor integrated circuit (IC) in a semiconductor test system, the 

5 method comprising: 

describing test system resources, test system configuration, and module configuration in 
general-purpose C/C++ constructs for the development of a test program to test the IC on the 
semiconductor test system; 

describing a test sequence in general-purpose C/C++ constructs for the development of 
10 the test program to test the IC on the semiconductor test system; 

describing a test plan in general-purpose C/C++ constructs for the development of the 
test program to test the IC on the semiconductor test system; 

describing test conditions in general-purpose C/C++ constructs for the development of 
the test program to test the IC on the semiconductor test system; 
1 5 describing test patterns in general-purpose C/C++ constructs for the development of the 

test program to test the IC on the semiconductor test system; and 

describing timing of the test patterns in general-purpose C/C++ constructs for the 
development of the test program to test the IC on the semiconductor test system. 

2. The method of claim 1 , wherein describing test system resources comprises: 

20 specifying a resource type, wherein the resource type is associated with at least one test 

module for applying a test to the IC; 

specifying a parameter type associated with the resource type, and 
specifying a parameter of the parameter type. 

3. The method of claim 1, wherein describing test system configuration comprises: 

25 specifying a site controller for controlling at least one test module, each test module for 

applying a test to the IC; and 

specifying an input port of a module connection enabler, 

wherein the test system couples the site controller to the module connection enabler at 
the input port, and the module connection enabler couples the site controller to the at least one 
30 test module. 

4. The method of claim 3, wherein the module connection enabler is a switch matrix. 

5. The method of claim 1, wherein describing module configuration comprises: 
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specifying a module identifier for specifying a module type; 

specifying executable code for controlling a test module 6f the module type specified by 
the module identifer, the test module for applying a test to the IC; and 
specifying a resource type associated with the test module. 
5 6. The method of claim 5, the method further comprising specifying a slot identifier for 
specifying an output port of a module connection enabler, wherein the test system couples the 
test module to the module connection enabler at the output port, and the module connection 
enabler couples the test module to a corresponding site controller. 
7. The method of claim 6, wherein the module connection enabler is a switch matrix. 
10 8. The method of claim 5, wherein the executable code is a dynamic link library. 

■ 

9. The method of claim 5, further comprising specifying a vendor identifier for identifying 
the provider of the test module. 

10. The method of claim 5, further comprising specifying an identifier of the maximum 
number of resource units available in connection with the resource type. 

15 11. The method of claim 5, wherein the resource type is digital tester pins and the resource 
units are tester channels. 

12. The method of claim 5, wherein the resource type is analog tester pins and the resource 
units are tester channels. 

13. The method of claim 5, wherein the resource type is RF tester pins and the resource 
20 units are tester channels. 

14. The method of claim 5, wherein the resource type is power supply pins and the resource 
units are tester channels. 

15. The method of claim 5, wherein the resource type is digitizer pins and the resource units 
are tester channels. 

25 1 6. The method of claim 5, wherein the resource type is arbitrary waveform generation pins 
and the resource units are tester channels. 

17. The method of claim 5, wherein the resource type is associated with resource units, the 
method further comprising specifying an indicator relating to which resource units are disabled. 

■ 

18. The method of claim 1 8, wherein resource units indicated as disabled represent 
30 defective resource units of the test module; 

19. The method of claim 1 , wherein describing test conditions comprises: 
specifying at least one test condition group. 

20. The method of claim 1 9, wherein describing test conditions further comprises: 
specifying at least one specification set including at least one variable; and 
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specifying a selector for selecting an expression to be bound to a variable. 

21. The method of claim 20 ; wherein association of the test condition group with a selector 
for the at least one specification set defines a test condition. 

22. The method of claim 21, wherein the test condition is an object. 

23. The method of claim 1, wherein describing a test sequence comprises specifying: 
a result of executing a flow or test; 

an action based upon the result; and 

* 

a transition to another flow or test based upon the result. 
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